If I have:
$ gcc -v -lm -lc math.o 2> logg
There are no libc or libm in the resulting link logg. Is that normal?
$ gcc --version
gcc (Ubuntu 4.9.1-16ubuntu6) 4.9.1
Related
I am using MacOS Mojave version 10.14.16 and I am trying to install http://www.rpl2.net/index.php (a programming language using Reverse Polish Notation as found on some HP calculators like the 48GX), supposed to work on MacOSX (they say "MacOS X (Xcode 3.1.4 + gfortran 4.5)").
So I have downloaded the latest stable release, cd to the folder, and wanted to run
./configure
make
make install
But the ./configure is failing due to "configure: error: Can not find libgomp !". There is no libgomp package I can install with brew (I already installed gcc which comes with gfortran and thought it would provide libgomp but apparently not).
Could someone help a poor applied mathematician trying to install a software on its macbook?
Thanks
EDIT
in my config.log I have this, maybe it will help:
configure:7433: checking for vim
configure:7449: found /usr/bin/vim
configure:7461: result: yes
configure:7507: checking for main in -lm
configure:7526: gcc -o conftest -g -O2 -O2 -fno-strict-overflow conftest.c -lm >&5
configure:7526: $? = 0
configure:7535: result: yes
configure:7548: checking for pthread_mutex_init in -lc
configure:7573: gcc -o conftest -g -O2 -O2 -fno-strict-overflow conftest.c -lc -lm >&5
configure:7573: $? = 0
configure:7582: result: yes
configure:7687: checking for omp_get_num_procs in -lgomp
configure:7712: gcc -o conftest -g -O2 -O2 -fno-strict-overflow conftest.c -lgomp -lc -lm >&5
ld: library not found for -lgomp
clang: error: linker command failed with exit code 1 (use -v to see invocation)
configure:7712: $? = 1
You don't say how you installed GCC. If you did it using homebrew, and
brew install gcc
you should be able to see:
/usr/local/Cellar/gcc/10.2.0/lib/gcc/10/libgomp.dylib
which would mean you need to compile with:
gcc ... -L /usr/local/Cellar/gcc/10.2.0/lib/gcc/10 -l gomp ...
Failing that, you can always search for libgomp with:
find /usr -name "lib*gomp*lib"
You can test which gcc you are using with:
type gcc
Consider the situation when a C++ project is built and shipped within a Centos 7 virtual machine or container. Default gcc for Centos 7 is 4.8. In order to allow developers to use modern C++, the more recent version of gcc (for example, 6.3) is installed into Centos 7 which runs as a CI server. This provides -std=c++14 support.
[builder#f7279ae9f33f build (master %)]$ /usr/bin/c++ -v 2>&1 | grep version
gcc version 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC)
[builder#f7279ae9f33f build (master %)]$ /opt/rh/devtoolset-6/root/usr/bin/c++ -v 2>&1 | grep version
gcc version 6.3.1 20170216 (Red Hat 6.3.1-3) (GCC)
export CXX=/opt/rh/devtoolset-6/root/usr/bin/c++
make all -j4
...
This is short example of compilation and linkage command:
[ 78%] Building CXX object CMakeFiles/ucsdos.dir/src/merge_operator_string.cpp.o
/opt/rh/devtoolset-6/root/usr/bin/c++ -Ducsdos_EXPORTS -I/home/builder/src/dos/libucsdos/./src -I/home/builder/src/dos/libucsdos/./include -I/home/builder/src/dos/libucsdos/build/schema/cpp -I/home/builder/src/dos/libucsdos/build/schema -isystem /usr/local/include -O2 -g -DNDEBUG -fPIC -frtti -pedantic -Wall -Wextra -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wdisabled-optimization -Wformat=2 -Winit-self -Wlogical-op -Wmissing-declarations -Wmissing-include-dirs -Wnoexcept -Wold-style-cast -Woverloaded-virtual -Wredundant-decls -Wshadow -Wsign-conversion -Wsign-promo -Wstrict-null-sentinel -Wstrict-overflow=5 -Wswitch-default -Wundef -Werror -Wno-unused -std=gnu++14 -o CMakeFiles/ucsdos.dir/src/merge_operator_string.cpp.o -c /home/builder/src/dos/libucsdos/src/merge_operator_string.cpp
[ 80%] Linking CXX shared library libucsdos.so
/usr/bin/cmake3 -E cmake_link_script CMakeFiles/ucsdos.dir/link.txt --verbose=1
/opt/rh/devtoolset-6/root/usr/bin/c++ -fPIC -O2 -g -DNDEBUG -shared -Wl,-soname,libucsdos.so.0 -o libucsdos.so.0.3.23 CMakeFiles/ucsdos.dir/src/c.cpp.o CMakeFiles/ucsdos.dir/src/crdt_2p_set.cpp.o CMakeFiles/ucsdos.dir/src/crdt_pn_counter.cpp.o CMakeFiles/ucsdos.dir/src/errors.cpp.o CMakeFiles/ucsdos.dir/src/merge_index_document.cpp.o CMakeFiles/ucsdos.dir/src/merge_index_segment.cpp.o CMakeFiles/ucsdos.dir/src/merge_operator_string.cpp.o -Wl,-rpath,/usr/local/lib: schema/libschema.a /usr/lib64/librocksdb.so /usr/lib64/libjemalloc.so /usr/local/lib/libgrpc++_reflection.so /usr/local/lib/libgrpc++.so /usr/local/lib/libgrpc.so -ldl -lgrpc++ /usr/lib64/libprotobuf.so -lpthread /usr/lib64/libprotobuf-lite.so
Anyway, the resulting artifacts appear to be linked with system default version of libstdc++:
[builder#f7279ae9f33f build (master %)]$ ldd libucsdos.so | grep libstdc++.so.6
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f2a4a054000)
It's easy to find out that /lib64/libstdc++.so.6 version is 4.8.5:
[builder#f7279ae9f33f build (master %)]$ yum whatprovides "/lib64/libstdc++.so.6"
libstdc++-4.8.5-28.el7_5.1.x86_64 : GNU Standard C++ Library
Repo : #Updates
Matched from:
Filename : /lib64/libstdc++.so.6
Is this build environment configuration valid?
Anyway, the resulting artifacts appear to be linked with system default version of libstdc++:
Yes. The devtoolset-6-gcc-c++ package provides a custom version of GCC that uses a special linker script instead of a dynamic library for libstdc++.so. That means the binaries it produces do not depend on the newer libstdc++.so.6 and can be run on other CentOS machines that don't have devtoolset installed (i.e. they only have the older libstdc++ library from GCC 4.8).
Is this build environment configuration valid?
Yes. What you're seeing is completely normal, and how it's supposed to work.
The pieces of the newer C++ runtime from GCC 6.4.0 get statically linked into your binary, and at runtime it only depends on the old libstdc++.so which every CentOS system has installed.
That's the whole point of the devtoolset version of GCC.
Consider the situation when a C++ project is built and shipped within a Centos 7 virtual machine or container. Default gcc for Centos 7 is 4.8. In order to allow developers to use modern C++, the more recent version of gcc (for example, 6.3) is installed into Centos 7 which runs as a CI server. This provides -std=c++14 support.
[builder#f7279ae9f33f build (master %)]$ /usr/bin/c++ -v 2>&1 | grep version
gcc version 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC)
[builder#f7279ae9f33f build (master %)]$ /opt/rh/devtoolset-6/root/usr/bin/c++ -v 2>&1 | grep version
gcc version 6.3.1 20170216 (Red Hat 6.3.1-3) (GCC)
export CXX=/opt/rh/devtoolset-6/root/usr/bin/c++
make all -j4
...
This is short example of compilation and linkage command:
[ 78%] Building CXX object CMakeFiles/ucsdos.dir/src/merge_operator_string.cpp.o
/opt/rh/devtoolset-6/root/usr/bin/c++ -Ducsdos_EXPORTS -I/home/builder/src/dos/libucsdos/./src -I/home/builder/src/dos/libucsdos/./include -I/home/builder/src/dos/libucsdos/build/schema/cpp -I/home/builder/src/dos/libucsdos/build/schema -isystem /usr/local/include -O2 -g -DNDEBUG -fPIC -frtti -pedantic -Wall -Wextra -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wdisabled-optimization -Wformat=2 -Winit-self -Wlogical-op -Wmissing-declarations -Wmissing-include-dirs -Wnoexcept -Wold-style-cast -Woverloaded-virtual -Wredundant-decls -Wshadow -Wsign-conversion -Wsign-promo -Wstrict-null-sentinel -Wstrict-overflow=5 -Wswitch-default -Wundef -Werror -Wno-unused -std=gnu++14 -o CMakeFiles/ucsdos.dir/src/merge_operator_string.cpp.o -c /home/builder/src/dos/libucsdos/src/merge_operator_string.cpp
[ 80%] Linking CXX shared library libucsdos.so
/usr/bin/cmake3 -E cmake_link_script CMakeFiles/ucsdos.dir/link.txt --verbose=1
/opt/rh/devtoolset-6/root/usr/bin/c++ -fPIC -O2 -g -DNDEBUG -shared -Wl,-soname,libucsdos.so.0 -o libucsdos.so.0.3.23 CMakeFiles/ucsdos.dir/src/c.cpp.o CMakeFiles/ucsdos.dir/src/crdt_2p_set.cpp.o CMakeFiles/ucsdos.dir/src/crdt_pn_counter.cpp.o CMakeFiles/ucsdos.dir/src/errors.cpp.o CMakeFiles/ucsdos.dir/src/merge_index_document.cpp.o CMakeFiles/ucsdos.dir/src/merge_index_segment.cpp.o CMakeFiles/ucsdos.dir/src/merge_operator_string.cpp.o -Wl,-rpath,/usr/local/lib: schema/libschema.a /usr/lib64/librocksdb.so /usr/lib64/libjemalloc.so /usr/local/lib/libgrpc++_reflection.so /usr/local/lib/libgrpc++.so /usr/local/lib/libgrpc.so -ldl -lgrpc++ /usr/lib64/libprotobuf.so -lpthread /usr/lib64/libprotobuf-lite.so
Anyway, the resulting artifacts appear to be linked with system default version of libstdc++:
[builder#f7279ae9f33f build (master %)]$ ldd libucsdos.so | grep libstdc++.so.6
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f2a4a054000)
It's easy to find out that /lib64/libstdc++.so.6 version is 4.8.5:
[builder#f7279ae9f33f build (master %)]$ yum whatprovides "/lib64/libstdc++.so.6"
libstdc++-4.8.5-28.el7_5.1.x86_64 : GNU Standard C++ Library
Repo : #Updates
Matched from:
Filename : /lib64/libstdc++.so.6
Is this build environment configuration valid?
Anyway, the resulting artifacts appear to be linked with system default version of libstdc++:
Yes. The devtoolset-6-gcc-c++ package provides a custom version of GCC that uses a special linker script instead of a dynamic library for libstdc++.so. That means the binaries it produces do not depend on the newer libstdc++.so.6 and can be run on other CentOS machines that don't have devtoolset installed (i.e. they only have the older libstdc++ library from GCC 4.8).
Is this build environment configuration valid?
Yes. What you're seeing is completely normal, and how it's supposed to work.
The pieces of the newer C++ runtime from GCC 6.4.0 get statically linked into your binary, and at runtime it only depends on the old libstdc++.so which every CentOS system has installed.
That's the whole point of the devtoolset version of GCC.
cat /etc/issue
Ubuntu 12.04.2 LTS \n \l
gcc --version
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
CFLAGS = -g -O2 -Wall -fPIC -c $(INCLUDES)
OFLAGS = -g -O2 -shared -Wall $(LIBS) -Wl,-soname,$(TARGET_NAME)
A cpp so, When I linked the so over, the dependency libs do not appear in ldd result. It's OK in CentOS6.3. the LD_LIBRARY_PATH is set OK because the ELF executable file I made is OK.
Thank you in advance.
G'day,
on a 64bit RHEL5 box we need to install our 32bit application. For some reasons we need to use gcc 4.0.3 for this, so I tried to install that version on the target machine first, like I did a thousand times on 32bit target platforms.
This time, however, I am experiencing problems. I have bootstrapped and instaled gcc 4.0.3 into a path, let's say /foo. Like always I set the LD_LIBRARY_PATH to point into the directory containing shared libraries:
$ echo $LD_LIBRARY_PATH
/foo/lib:/foo/lib/gcc/x86_64-unknown-linux-gnu/lib64:/foo/lib/gcc/x86_64-unknown-linux-gnu/4.0.3:/lib64
There really are the necessary libraries in these directories:
$ ls /foo/lib/gcc/x86_64-unknown-linux-gnu/lib64
libgcc_s.so libgcc_s.so.1
$ ls /foo/lib/gcc/x86_64-unknown-linux-gnu/4.0.3
32 crtendS.o libgcov.a libmudflap.so.0.0.0 libmudflapth.so.0.0.0 libstdc++.so.6.0.7
crtbegin.o include libmudflap.a libmudflapth.a libstdc++.a libsupc++.a
crtbeginS.o install-tools libmudflap.la libmudflapth.la libstdc++.la libsupc++.la
crtbeginT.o libgcc.a libmudflap.so libmudflapth.so libstdc++.so
crtend.o libgcc_eh.a libmudflap.so.0 libmudflapth.so.0 libstdc++.so.6
However, if I try to create a simple program, ld can't find libgcc_s:
$ gcc-4.0 t.cc
/foo/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.0.3/../../../../x86_64-unknown-linux-gnu/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status
Why doesn't it find the libgcc_s.so library?
Any help appreciated!
Stefan
It seems your folder /foo/lib/gcc/x86_64-unknown-linux-gnu/lib64 where libgcc_s.so is not included. For the sake of experiment do this:
gcc-4.0 -v t.cc -L/foo/lib/gcc/x86_64-unknown-linux-gnu/lib64
$ gcc-4.0 -v t.cc
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.0.3/configure --prefix=/foo --program-suffix=-4.0 --enable-version-specific-runtime-libs --enable-languages=c,c++ --with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 4.0.3
/foo/i686-pc-linux-gnu/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.0.3/cc1plus -quiet -v -iprefix /foo/i686-pc-linux-gnu/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.0.3/ -D_GNU_SOURCE t.cc -quiet -dumpbase t.cc -mtune=k8 -auxbase t -version -o /tmp/ccDiWiMk.s
ignoring nonexistent directory "/foo/i686-pc-linux-gnu/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.0.3/../../../../x86_64-unknown-linux-gnu/include"
ignoring duplicate directory "/foo/lib/gcc/x86_64-unknown-linux-gnu/4.0.3/include/c++"
ignoring duplicate directory "/foo/lib/gcc/x86_64-unknown-linux-gnu/4.0.3/include/c++/x86_64-unknown-linux-gnu"
ignoring duplicate directory "/foo/lib/gcc/x86_64-unknown-linux-gnu/4.0.3/include/c++/backward"
ignoring duplicate directory "/foo/lib/gcc/x86_64-unknown-linux-gnu/4.0.3/include"
ignoring nonexistent directory "/foo/lib/gcc/x86_64-unknown-linux-gnu/4.0.3/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include search starts here:
/foo/i686-pc-linux-gnu/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.0.3/include/c++
/foo/i686-pc-linux-gnu/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.0.3/include/c++/x86_64-unknown-linux-gnu
/foo/i686-pc-linux-gnu/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.0.3/include/c++/backward
/foo/i686-pc-linux-gnu/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.0.3/include
/usr/local/include
/foo/include
/usr/include
End of search list.
GNU C++ version 4.0.3 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.1.2 20080704 (Red Hat 4.1.2-46).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
/foo/i686-pc-linux-gnu/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.0.3/../../../../x86_64-unknown-linux-gnu/bin/as -V -Qy -o /tmp/ccAemlDJ.o /tmp/ccDiWiMk.s
GNU assembler version 2.19.1 (x86_64-unknown-linux-gnu) using BFD version (GNU Binutils) 2.19.1
/foo/i686-pc-linux-gnu/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.0.3/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /foo/i686-pc-linux-gnu/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.0.3/crtbegin.o -L/foo/i686-pc-linux-gnu/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.0.3 -L/foo/i686-pc-linux-gnu/bin/../lib/gcc -L/foo/lib/gcc/x86_64-unknown-linux-gnu/4.0.3 -L/foo/i686-pc-linux-gnu/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.0.3/../../../../x86_64-unknown-linux-gnu/lib -L/foo/lib/gcc/x86_64-unknown-linux-gnu/4.0.3/../../../../x86_64-unknown-linux-gnu/lib -L/foo/i686-pc-linux-gnu/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.0.3/../../../../lib64 -L/foo/i686-pc-linux-gnu/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.0.3/../../.. -L/foo/lib/gcc/x86_64-unknown-linux-gnu/4.0.3/../../../../lib64 -L/foo/lib/gcc/x86_64-unknown-linux-gnu/4.0.3/../../.. -L/lib/../lib64 -L/usr/lib/../lib64 /tmp/ccAemlDJ.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /foo/i686-pc-linux-gnu/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.0.3/crtend.o /usr/lib/../lib64/crtn.o
/foo/i686-pc-linux-gnu/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.0.3/../../../../x86_64-unknown-linux-gnu/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status