I have a technical issue compiling with mpicc - linux

My gcc works fine when I compile '''gcc''' but I'm trying to compile a C program with '''mpicc''' and my terminal returns this error, which deletes also the script:
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
The compiling instructions are: mpicc -o p35.c.
How could I solve this?
My gcc version:
gcc --version
gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
My mpicc version:
mpicc --version
gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Thanks.

Compiling Command is Wrong
mpicc p35.c -o p35.out
Now run p35.out file
./p35.out
I think you got this.

Related

How to use patchelf with --set-interpreter?

I'm trying to do the following:
Change the libc of a simple test.c from the system default (Debian 9.11, libc-2.24.so) to libc 2.27.
This is my attempt:
user#pc:~/patchelf_test$ cat test.c
#include <stdio.h>
int main(int argc, char **argv)
{
printf("hello patchelf\n");
return 0;
}
user#pc:~/patchelf_test$ gcc test.c -o test
user#pc:~/patchelf_test$ ./test
hello patchelf
user#pc:~/patchelf_test$ ldd test
linux-vdso.so.1 (0x00007ffd9d1d8000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7ea0290000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7ea0831000)
user#pc:~/patchelf_test$ patchelf --set-interpreter ./libc6-amd64_2.27-3ubuntu1_i386.so test
warning: working around a Linux kernel bug by creating a hole of 2093056 bytes in ‘test’
user#pc:~/patchelf_test$ ldd test
linux-vdso.so.1 (0x00007fff20b9a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa46a35e000)
./libc6-amd64_2.27-3ubuntu1_i386.so => /lib64/ld-linux-x86-64.so.2 (0x00007fa46a900000)
user#pc:~/patchelf_test$ ./test
GNU C Library (Ubuntu GLIBC 2.27-3ubuntu1) stable release version 2.27.
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 7.3.0.
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<https://bugs.launchpad.net/ubuntu/+source/glibc/+bugs>.
user#pc:~/patchelf_test$
The expected result here, is that it should run the actual program. Actual results, are that it runs the linker itself.
Question: How do I need to modify my command to fix this?
I've also tried to use libc6-amd64_2.27-3ubuntu1_i386.ld instead of .so:
user#pc:~/patchelf_test$ !gcc
gcc test.c -o test
user#pc:~/patchelf_test$ patchelf --set-interpreter ./libc6-amd64_2.27-3ubuntu1_i386.ld test
warning: working around a Linux kernel bug by creating a hole of 2093056 bytes in ‘test’
user#pc:~/patchelf_test$ ./test
Segmentation fault
I've also tried to use my system default libc, and patch with that, just to establish that patchelf works at all, but again I get the same problem -- it executes the linker binary itself, instead of the test binary.
user#pc:~/patchelf_test$ !gcc
gcc test.c -o test
user#pc:~/patchelf_test$ patchelf --set-interpreter ./libc_default.so test
warning: working around a Linux kernel bug by creating a hole of 2093056 bytes in ‘test’
user#pc:~/patchelf_test$ ./test
GNU C Library (Debian GLIBC 2.24-11+deb9u4) stable release version 2.24, by Roland McGrath et al.
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 6.3.0 20170516.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.debian.org/Bugs/>.
strace:
$ strace ./test
execve("./test", ["./test"], [/* 44 vars */]) = 0
write(1, "GNU C Library (Debian GLIBC 2.24"..., 616GNU C Library (Debian GLIBC 2.24-11+deb9u4) stable release version 2.24, by Roland McGrath et al.
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 6.3.0 20170516.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.debian.org/Bugs/>.
) = 616
exit_group(0) = ?
+++ exited with 0 +++
This command makes no sense:
patchelf --set-interpreter ./libc6-amd64_2.27-3ubuntu1_i386.so test
libc.so.6 and ld-linux.so.2 are not at all the same, and you are setting PT_INTERP to (equivalent of) libc.so.6.
This command is "correct":
patchelf --set-interpreter ./libc6-amd64_2.27-3ubuntu1_i386.ld test
but the result crashes most likely due to system GLIBC being a different version. As I said here, ld-linux and libc.so.6 must match exactly.
To make this all work, you should get rid of the funny libc-amd64... naming convention, fully extract the 2.27 build into e.g. ./libc6-amd64_2.27/ directory, then use something like:
patchelf --set-interpreter ./libc6-amd64_2.27/lib64/ld-linux-x86-64.so.2 test
LD_LIBRARY_PATH=./libc6-amd64_2.27/lib64 ./test

Building cross compiler: pthread.h: No such file or directory

I'm currently trying to compile my own gcc 9.1.0 cross compiler for aarch64-linux-gnu target. I used this tutorial: https://wiki.osdev.org/GCC_Cross-Compiler
The compile progress for the gcc and g++ compiler seems to finish without errors, but allways when I try to compile libgcc with the command make all-target-libgcc I run into this error:
In file included from ../../../gcc-9.1.0/libgcc/gthr.h:148,
from ../../../gcc-9.1.0/libgcc/libgcov-interface.c:27:
./gthr-default.h:35:10: fatal error: pthread.h: No such file or directory
35 | #include <pthread.h>
| ^~~~~~~~~~~
compilation terminated.
g++ --version on my build maschine prints:
g++ (GCC) 9.1.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
And my configuration command for gcc is:
../gcc-9.1.0/configure --target=$TARGET --prefix="$PREFIX" --disable-nls --without-headers
With:
export TARGET=aarch64-linux-gnu
export PREFIX=/opt/aarch64-linux-gnu
What do I forget?
From GCC installation manual:
In order to build GCC, the C standard library and headers must be
present for all target variants for which target libraries will be
built (and not only the variant of the host C++ compiler).
So you need a libc for aarch64.
If you want to build it yourself, Preshing has a good article on the topic, which I haven't read in full but recommend anyway. He even has a picture mentioning both pthread.h and libgcc.a.
AFAIK, GCC can pick up a symlink to newlib sources and build it automatically during the course of building a full cross compiler with target libraries. Not sure about Glibc.

How to compile latest sources using older gcc glibc versions and run them?

I'm able to compile & run the latest "stockfish chess engine" sources using GCC 4.8 or later on Redhat EL 7.X. The latest source code (alongwith README) is available at https://github.com/mcostalba/Stockfish/tree/master
The commands to compile & build are: (goto "src" directory)
gmake build ARCH=x86-64
gmake install
However my requirement is to compile & run the same on Redhat EL 6.7 Server where the latest GCC version available is 4.4.7 (& glibc 2.12) as I can NOT upgrade GCC version without actually migrating to RHEL 7.X
Is it possible to modify the latest source to get it compliled & run on old version of gcc/glibc? if yes, would anyone be able to modify the sources (perhaps just Makefile?) for me please?
I tried changing "C ++ 11" to "C ++ 0x" in the "Makefile" but no luck. Please see the error I'm getting when I try to compile latest SF source with GCC 4.4.7:
[root#test-server src]# ldd --version
ldd (GNU libc) 2.12
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
[root#test-server src]# gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[root#test-server src]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.7 (Santiago)
[root#test-server src]# uname -r
2.6.32-573.12.1.el6.x86_64
[root#test-server src]# gmake build ARCH=x86-64
gmake ARCH=x86-64 COMP=gcc config-sanity
gmake[1]: Entering directory `/root/Stockfish-master/src'
Config:
debug: 'no'
optimize: 'yes'
arch: 'x86_64'
bits: '64'
prefetch: 'yes'
popcnt: 'no'
sse: 'yes'
pext: 'no'
Flags:
CXX: g++
CXXFLAGS: -Wall -Wcast-qual -fno-exceptions -fno-rtti -std=c++11 -pedantic -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto
LDFLAGS: -Wl,--no-as-needed -lpthread -Wall -Wcast-qual -fno-exceptions -fno-rtti -std=c++11 -pedantic -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto
Testing config sanity. If this fails, try 'make help' ...
gmake[1]: Leaving directory `/root/Stockfish-master/src'
gmake ARCH=x86-64 COMP=gcc all
gmake[1]: Entering directory `/root/Stockfish-master/src'
g++ -Wall -Wcast-qual -fno-exceptions -fno-rtti -std=c++11 -pedantic -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto -c -o benchmark.o benchmark.cpp
cc1plus: error: unrecognized command line option "-std=c++11"
cc1plus: error: unrecognized command line option "-flto"
gmake[1]: * [benchmark.o] Error 1
gmake[1]: Leaving directory `/root/Stockfish-master/src'
gmake: * [build] Error 2
[root#test-server src]#
Many thanks in advance!
Is it possible to modify the latest source to get it compliled & run
on old version of gcc/glibc? if yes, would anyone be able to modify
the sources (perhaps just Makefile?) for me please?
Sure it's possible. It will take time and effort though.
I can NOT upgrade GCC version without actually migrating to RHEL 7.X
You can't install the GCC binary from RHEL you mean. But if you have one compiler you can have another.
You have a few options which allow you to manually compile your own GCC and install it to /opt or /usr/local without messing your system.
You can do it manually or use a tool chain like installing gentoo`s portage or bootstrapping pkgsrc which offers gcc-4.8
Although, I am an avid gentoo user, I recommend using pkgsrc on foreign architectures. It's very easy to get started with, and have a vast number of packages.

"cmath: No such file or directory" when compiled with GCC

I wrote the simple program in linux ubuntu, when I use g++ there is no error but when I use gcc I see this error:
test.c:1:17: fatal error: cmath: No such file or directory #include <cmath>
Note : "as a matter of fact I see this error in compiling the package, I thought it might be related to gcc library which is not set to linux environment, so I wrote the simple program to determine the error clearly and whitout dependency!"
so the program should compile with gcc so that I can over come the main problem.
I khow that I can use math.h instead of cmath, but the packege used the cmath!
this is the simple program:
/*test.c*/
#include <cmath>
#include <iostream>
#include <stdio.h>
#include <stdlib.h>
using namespace std;
int main(){
double sinx = sin(3.14/3);
cout<< "sinx= " << sinx;
return 0;
}
here is cmath pathes:
root#geant4:/# find -name cmath
./opt/root5.32.00/cint/cint/include/cmath
./app/gcc/4.8.0/include/c++/4.8.0/ext/cmath
./app/gcc/4.8.0/include/c++/4.8.0/cmath
./app/gcc/4.8.0/include/c++/4.8.0/tr1/cmath
./usr/include/boost/compatibility/cpp_c_headers/cmath
./usr/include/boost/tr1/tr1/cmath
./usr/include/c++/4.5/cmath
./usr/include/c++/4.5/tr1_impl/cmath
./usr/include/c++/4.5/tr1/cmath
./usr/include/c++/4.6/cmath
./usr/include/c++/4.6/tr1/cmath
./usr/share/gccxml-0.9/GCC/2.95/cmath
./gcc-build/gcc-4.8.0/stage1-i686-pc-linux-gnu/libstdc++-v3/include/ext/cmath
./gcc-build/gcc-4.8.0/stage1-i686-pc-linux-gnu/libstdc++-v3/include/cmath
./gcc-build/gcc-4.8.0/stage1-i686-pc-linux-gnu/libstdc++-v3/include/tr1/cmath
./gcc-build/gcc-4.8.0/i686-pc-linux-gnu/libstdc++-v3/include/ext/cmath
./gcc-build/gcc-4.8.0/i686-pc-linux-gnu/libstdc++-v3/include/cmath
./gcc-build/gcc-4.8.0/i686-pc-linux-gnu/libstdc++-v3/include/tr1/cmath
./gcc-build/gcc-4.8.0/libstdc++-v3/include/ext/cmath
./gcc-build/gcc-4.8.0/libstdc++-v3/include/c/cmath
./gcc-build/gcc-4.8.0/libstdc++-v3/include/c_global/cmath
./gcc-build/gcc-4.8.0/libstdc++-v3/include/c_std/cmath
./gcc-build/gcc-4.8.0/libstdc++-v3/include/tr1/cmath
./gcc-build/gcc-4.8.0/libstdc++-v3/testsuite/26_numerics/headers/cmath
./gcc-build/gcc-4.8.0/libstdc++-v3/testsuite/tr1/8_c_compatibility/cmath
./gcc-build/gcc-4.8.0/prev-i686-pc-linux-gnu/libstdc++-v3/include/ext/cmath
./gcc-build/gcc-4.8.0/prev-i686-pc-linux-gnu/libstdc++-v3/include/cmath
./gcc-build/gcc-4.8.0/prev-i686-pc-linux-gnu/libstdc++-v3/include/tr1/cmath
and after installing gcc-4.8 I did this instruction:
root#geant4:~/Desktop# update-alternatives --install /usr/bin/gcc gcc /app/gcc/4.8.0/bin/gcc 40 --slave /usr/bin/g++ g++ /app/gcc/4.8.0/bin/g++
root#geant4:~/Desktop#update-alternatives --install /usr/bin/gcc gcc /app/gcc/4.8.0/bin/gcc 60 --slave /usr/bin/g++ g++ /app/gcc/4.8.0/bin/g++
root#geant4:~/Desktop# update-alternatives --config gcc
to make gcc-4.8 my default gcc.
now
root#geant4:~/Desktop# gcc --version
gcc (GCC) 4.8.0
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
as a matter of fact I wrote the main problem in https://askubuntu.com/questions/309195/cmath-no-such-file-or-directory-include-cmath
please help me
I don`t know what to do.
thanks
Some basics::
GCC:: GNU Compiler Collection
G++:: GNU C++ Compiler
Both are drivers which calls the compilers as needed.
Clearing your doubt::
The problem with GCC is that it doesn't links in the std C++ libraries by default as G++ does. GCC is just a front-end. The actual compiler is cc1plus. So it is always advisable to use G++ when compiling C++ files. The result can be same with both GCC and G++ if you do know the exact arguments to link them. You may find this link helpful.
But if you still want to use GCC, use it with linker-option -lstdc++ at the end of the command. This linker-option is added by default when you use G++. You can verify this by compiling your code using GCC with -### option and it will show you that -lstdc++ option is missing.
Compile C++ source files with g++, not gcc.

g++ throwing file not recognized: File format not recognized error

getting following error with the command g++ -o test -L . -l pq
libpq.so: file not recognized: File format not recognized
#file libpq.so
libpq.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), not stripped
gcc version 4.1.2 20070115 (SUSE Linux)
I am getting the same error if I try to use -l dbodbc instead of -l pq.
Note that test.c is a simple hello world program.
Thanks in Advance.
file /usr/bin/g++ tells you that g++ itself is a 64-bit executable, i.e. it runs on a 64-bit machine, it doesn't tell you that g++ can compile 64-bit code (it's very unlikely but it could be a cross compiler for a completely different processor!) Use g++ -v or g++ -dumpmachine to find out what target it generates executables for.
G++ doesn't actually use that library, it just passes the -l option to the linker, so the error is coming from the linker, ld
If ld and objdump are both saying they can't recognize the library but the same file is fine on a different machine, I would try updating or reinstalling the binutils package, which provides both ld and objdump.
You might have a 32-bit binutils installed, so its ld and objdump wouldn't understand the x86_64 library. Ensure you have the 64-bit (i.e. x86_64) binutils RPM installed.

Resources