I am trying to statically link the libraries while compiling a C++ program.
g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4)
$ g++ -std=c++11 -I/home/jerry/Desktop/tiny-dnn -m32 -pthread -static train.cpp -o train
/usr/bin/ld: cannot find -lstdc++
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lpthread
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
I found this post
(/usr/bin/ld: cannot find -lc while compiling with makefile ) that says to to install glibc-static.
bash-4.2# sudo yum install glibc-static
Loaded plugins: langpacks
ol7_UEKR3 | 1.2 kB 00:00:00
ol7_latest | 1.4 kB 00:00:00
No package glibc-static available.
Error: Nothing to do
bash-4.2# yum info glibc-static
Loaded plugins: langpacks
Error: No matching Packages to list
bash-4.2# yum search glibc
Loaded plugins: langpacks
================================================== N/S matched: glibc ===================================================
glibc-common.x86_64 : Common binaries and locale data for glibc
compat-glibc.x86_64 : Compatibility C library
compat-glibc-headers.x86_64 : Header files for development using standard C libraries.
glibc.i686 : The GNU libc libraries
glibc.x86_64 : The GNU libc libraries
glibc-devel.i686 : Object files for development using standard C libraries.
glibc-devel.x86_64 : Object files for development using standard C libraries.
glibc-headers.x86_64 : Header files for development using standard C libraries.
glibc-utils.x86_64 : Development utilities from GNU C library
kdesdk-kmtrace.x86_64 : Assist with malloc debugging using glibc's "mtrace" functionality
kernel-headers.x86_64 : Header files for the Linux kernel for use by glibc
latrace.i686 : LD_AUDIT feature frontend for glibc 2.4+
latrace.x86_64 : LD_AUDIT feature frontend for glibc 2.4+
Name and summary matches only, use "search all" for everything.
How can I install glibc-static? Please help.
Thanks.
glibc-static is only available in the Optional channels. RPM packages in the Optional channels are officially unsupported, which is why these channels are not enabled by default.
The exact command to enable optional channels depends on the product variant. Something like
subscription-manager repos --enable=rhel-7-server-optional-rpms
could work, but the details depend on your environment (and it's more a sysadmin than a programming matter at this point).
Note: There is are very good reasons why static linking is not supported by Red Hat. You really should avoid it.
I had this issue in the Docker container for Centos 8. I found that the following worked:
dnf --enablerepo=powertools install glibc-static
This was suggested from this packages site
you should user glibc-static to compile static bin
Related
I have installed fftw and boost with conda;
conda install -c https://conda.anaconda.org/anaconda boost
conda install -c https://conda.anaconda.org/nlesc fftw
tmv with scons
tmv0.72){58}> scons install PREFIX=/home/rgm/local
the scons with the various variables specified earlier as shown below:
scons
scons: Reading SConscript files ...
SCons is version 2.3.5 using python version 2.7.10
Python is from /System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
Using the following (non-default) scons options:
PREFIX = /home/rgm/local/
TMV_DIR = /Users/rgm/local
FFTW_DIR = /Users/rgm/anaconda/
BOOST_DIR = /Users/rgm/anaconda/
These can be edited directly in the file gs_scons.conf.
Type scons -h for a full list of available options.
Using python = /home/rgm/anaconda/bin/python
Using default PYPREFIX = /home/rgm/anaconda/lib/python2.7/site-packages
Using compiler: /home/rgm/anaconda/bin/g++
compiler version: 4.8.5
Determined that a good number of jobs = 4
Checking for C++ header file fftw3.h... yes
Checking for correct FFTW linkage... yes
Checking for boost header files... yes
Boost version is 1.57.0
Checking for C++ header file TMV.h... yes
TMV version is 0.72
Using TMV_LINK file: /Users/rgm/local/share/tmv/tmv-link
-L/home/rgm/local/lib -ltmv -lblas -lpthread -fopenmp
Mac version is 10.10.5
XCode version is 7.2
Checking for correct TMV linkage... (this may take a little while)
Checking for correct TMV linkage...
Error: TMV file failed to link correctly
Check that the correct location is specified for TMV_DIR
looking in config.log there are lines like:
Undefined symbols for architecture x86_64:
"_fftw_destroy_plan", referenced from:
_main in conftest_2.o
The proximate problem here is that it cannot find the OpenMP library (libgomp.1.dylib) at runtime. Here are the relevant lines from the config.log:
g++ -o .sconf_temp/conftest_16 -fopenmp .sconf_temp/conftest_16.o -Llib -L/Users/rgm/anaconda/lib -L/Users/rgm/local/lib -L/home/rgm/local/lib -ltmv_symband -lfftw3 -lpthread -ltmv -lblas -lpthread
.sconf_temp/conftest_16 > .sconf_temp/conftest_16.out
dyld: Library not loaded: #rpath/./libgomp.1.dylib
Referenced from: /data/vault/rgm/soft/MACOS/GalSim/.sconf_temp/conftest_16
Reason: image not found
sh: line 1: 20592 Trace/BPT trap: 5 .sconf_temp/conftest_16 > ".sconf_temp/conftest_16.out"
I've had similar troubles with Anaconda before on Macs. They seem to try to force the Mac to use Unix-style run-time library resolution, rather than follow the normal way Macs do it, which is fundamentally different. In particular, this #rpath thing works really nicely on Linux/Unix systems, but not so much on Macs. I guess with their own conda-installed libraries, they have a way to make it all work correctly , but it doesn't mesh very well with outside libraries that are installed in the normal Mac way.
Anyway, since it's just the OpenMP stuff in TMV, and the matrix operations in GalSim are never time critical, your easiest option is probably to install TMV without OpenMP support using scons install WITH_OPENMP=false.
Then try installing GalSim again.
Can you (reasonably) get Fedora 21 to where it only has llvm/clang/libc++/libc++abi? (I found some things suggesting no, but they were all about 3 years old, and llvm/clang has come a long way since then.)
With a fresh install, I tried
yum install gcc gcc-c++
(downloaded, built, installed llvm/cfe(clang)/compiler-rt/libcxx/libcxxabi from svn)
yum remove gcc gcc-c++
added to /etc/profile: export CC=/usr/local/bin/clang \ export CXX=/usr/local/bin/clang++
(in case of hard wiring)
ln -s /usr/local/bin/clang /usr/local/bin/gcc
ln -s /usr/local/bin/clang /usr/local/bin/cc
ln -s /usr/local/bin/clang++ /usr/local/bin/g++
ln -s /usr/local/bin/clang++ /usr/local/bin/c++
ldconfig
I was all happy, then went to build something, and I got:
ld: cannot find crtbegin.o
ld: cannot find -lgcc
ld: cannot find -lgcc_s
clang -v includes
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.9.2
ldconfig && ldconfig -p | grep libgcc does show
libgcc_s.so.1 (libc6,x86-64) => /lib64/libgcc_s.so.1
And /lib64 is a symlink to /usr/lib64. And, /usr/lib64/libgcc_s.so.1 is a symlink to /usr/lib64/libgcc_s-4.9.2-20150212.so.1, which exists as a real file (92816 bytes.)
So, I don't get what ld's problem is on -lgcc_s. crtbegin is nowhere to be found, and gcc (no _s) is nowhere to be found.
yum install libgcc says it's already installed and latest version, nothing to do.
Since I have an installed clang source build, can I re-build clang, this time using clang rather than gcc, to get rid of the dependency? (Maybe then the "candidate GCC installation" bit goes away.)
Can I force -stdlib=c++ and -lc++abi to be default, or at least have libc++ and libc++abi installed without gcc?
Having spent some time trying to get clang to work with libc++ and libc++abi without GCC, I have found that it is indeed possible, even if a bit problematic given the current state of LLVM/clang. In addition to small test programs, I've been able to build CMake and some other software packages written in C++ with no GCC installed, and with the resulting binaries being independent of libstdc++; they only depend on libc++/libc++abi according to ldd output. Unfortunately, I haven't been able to build clang itself with clang that was build using GCC. I've been experimenting on different Linux platforms (Fedora 21 32-bit, Amazon Linux release 2015.3 (RPM-based) 64-bit, CentOS 7.1 64-bit, and Ubuntu 14.04 64-bit).
Even though one can build software with clang using libc++/libc++abi without dependency on libstdc++ and without GCC compiler present, a typical Linux installation is so tied to libgcc and libstdc++ that getting rid of these is not practical. Try removing these two packages and you will see how much of the system depends on them. Even on FreeBSD 10.1, with clang being the default compiler and no GCC installed, libgcc.a, libgcc_s.so, and a few crt*.o files are used when building a program as revealed by the -v option. Also, on FreeBSD 10.1, resulting binaries depend on libgcc according to ldd. On Ubuntu, which has dpkg as the package manager, the files
libgcc.a
libgcc_s.so
crtbegin.o
crtbeginT.o
crtbeginS.o
crtendS.o
crtend.o
are in the libgcc-devel package, while on an RPM-based system, such as Fedora, these are in the gcc package. In addition, you might possibly need these files, even though I didn't need them for the code I tried building:
crtfastmath.o
crtprec32.o
crtprec80.o
crtprec64.o
Thus one might argue that the aforementioned files better belong in libgcc, rather than in gcc. As far as I can tell, the following needs to be done on an RPM-based system before removing the gcc package:
1) Create the symlink
libgcc_s.so -> libgcc_s.so.1
in whatever directory libgcc_s.so.1 is located.
2) Copy the crt*.o files listed above to that directory.
3) In the same directory create the symlink (libstdc++.so.x should already be there; x is a number):
libstdc++.so -> libstdc++.so.x
You only need this if you are going to use libstdc++; this isn't needed if you only plan to use libc++. On some
systems libstdc++.so, which is a symlink to libstdc++.so.x belonging to the libstdc++ package, is placed by the libstdc++-devel package into the GCC library directory, so you can remove that directory after uninstalling GCC and just create the symlink in the same directory where libstdc++.so.x lives.
Now you should be able to do the following:
1) Build a C program:
clang progname.c
2) Build a C++ program using libstdc++ headers/libs:
clang++ -I<location of headers> progname.cpp
On RPM-based systems I've looked at, the libstdc++ headers are part of the libstdc++-devel package and their location can be found from rpm -ql on the package.
3) Build a C++ program using libc++ headers/libs:
clang++ -I/<location of headers> progname.cpp -nodefaultlibs -lc++ -lc++abi -lm -lc -lgcc -lgcc_s
The location of the headers is wherever they were installed when you built LLVM+clang etc.
Please see http://libcxx.llvm.org/ for additional information. When building C++ code using libc++/libc++abi, you may use -stdlib=libc++ instead of the -I flag, but in my testing that only worked with clang built from source, not with clang installed from a repository (you can install clang from repo and use it to build libc++/libc++abi; or you can use gcc to build libc++(abi), then remove gcc and use the libs with the repo-provided clang).
When configuring a software package to build it using clang + libc++, you might need to set the following:
LIBS="-nodefaultlibs -lc++ -lc++abi -lm -lc -lgcc_s -lgcc"
CXX=clang++
CXXFLAGS="-stdlib=libc++"
CC=clang
Please note that to configure CMake source in order to build it I had to use a wrapper script like this:
#!/bin/bash
MYLFLAGS="-nodefaultlibs -lc++ -lc++abi -lm -lc -lgcc_s -lgcc"
# Catch the case when we only want to compile; this helps us avoid some warnings:
if echo "$#" | egrep "(^-c | -c | -c$)" >/dev/null 2>&1; then
MYLFLAGS=""
fi
/usr/local/bin/clang++ -stdlib=libc++ "$#" $MYLFLAGS
It might be useful for other purposes as well.
For more information please see my article at http://www.omniprog.info/clang_no_gcc.html
Unfortunately I'm forced to use gcc-4.1 and I'm using debian wheezy. Since gcc-4.1 is not in repository I'm trying to build gcc from sources.
But I'm getting compiling error:
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libc.a when searching for -lc
/usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/x86_64-linux-gnu/crti.o' is incompatible with i386 output
/usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/x86_64-linux-gnu/crtn.o' is incompatible with i386 output
It looks that ld is picking wrong version of libraries, but I checked my /usr/lib32 and /usr/lib/x86_64-linux-gnu/ and it contains those files:
/usr/lib32/libc.a
/usr/lib32/libc.so
/usr/lib32/crtn.o
/usr/lib32/crti.o
/usr/lib/x86_64-linux-gnu/libc.a
/usr/lib/x86_64-linux-gnu/libc.so
/usr/lib/x86_64-linux-gnu/crtn.o
/usr/lib/x86_64-linux-gnu/crti.o
And ld should have access to them
~$ echo $LIBRARY_PATH
/usr/lib/x86_64-linux-gnu:/usr/lib32/
So I have no idea where the problem is.
I managed to work around the problem.
Run configure with:
./configure --disable-multilib ...
But than I encountered another problem with makeinfo, if you have newer version >=4.10 than it might not be found by configure. So simple fix in generated makefile worked for me:
Change this line:
MAKEINFO = /home/lecopivo/Downloads/gcc412/gcc412/gcc-4.1.2/missing makeinfo
To this:
MAKEINFO = makeinfo
I found this helpful.
LD_LIBRARY_PATH is only for running programs already linked.
You probably need to set LDFLAGS when you configure gcc:
./configure LDFLAGS="-L/usr/lib32" .....
It might be LDFLAGS_FOR_HOST or LIBS or something like that though.
I had this problem recently and finally solved it this way:
ln -s /usr/lib32 /usr/lib/i386-linux-gnu
Notes:
I assumed you do not have /usr/lib/i386-linux-gnu directory in your 64bit linux. If this directory exists and is empty, please delete it and make the above link.
If the directory already exists and is not empty, you have to make links inside it for (32bit) libraries which cause build error one by one; e.g.:
ln -s /usr/lib32/crti.o /usr/lib/i386-linux-gnu/crti.o
ln -s /usr/lib32/crtn.o /usr/lib/i386-linux-gnu/crtn.o
...
If 32bit development libraries are not installed, you may have to install them first. I've searched different forums and found that installing following set of packages in ubuntu will provide them:
libc6-dev libc6-dev-i386
gcc-multilib g++-multilib
zlib1g-dev lib32z1-dev
libncurses5-dev lib32ncurses5-dev libncursesw5-dev lib32ncursesw5-dev
Also adjust LD_LIBRARY_PATH and LIBRARY_PATH variables so that they contain /usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu (i.e. multiarch lib-dirs). I am not sure which one of above variables is effective, so I adjust both of them the same.
If you use ./configure --disable-multilib as it is frequently suggested on web, though gcc will be built, but when you want to use that gcc for compiling e.g. legacy grub, you probably get error of "gcc cannot build executable" (or such).
Optionally, you can make similar linking for these pair of libdirs:
ln -s /lib32 /lib/i386-linux-gnu
Doing so, I managed to compile gcc-3.4.6 in a Ubuntu 16.04.6-amd64 used for compiling old 32bit programs like SDL 1.2 and legacy GRUB4DOS 0.4.4.
Also take a look at my answer to similar (though opposite) error here.
Good luck.
I am using Ubuntu and gcc and g++ were working fine but today it showed:
cannot find -lm
cannot find -lc
I searched and found it has something to do with /usr/bin/ld. Which is a symlink (I hope) to lbd.bdf. I pasted that file in the directory from Ubuntu of some friends PC. It didn't work.
I found that -lc means include static library libc.a.
similarly for -lm
I found them in my i386-linux-folders (name was something different).
I tried code blocks but same errors.
The compiler cannot find static glibc, you might have installed only the shared libraries, try:
yum install glibc-static
make sure that your libpath (in g++) points to the directory(ies) that libm.a and libc.a are located in (use the -L option)
ld is the GNU linker.
man ld
ld combines a number of object and archive files, relocates their data and ties up symbol references. Usually the last step in compiling a program is to run ld.
It is uses to link your program with the C library and the C math library. You need to make sure that libc6-dev is installed:
foo#bar: $ dpkg -s libc6-dev
Or more generic, ensure build-essential, which depends on a handful of essential C packages.
foo#bar: $ dpkg -s build-essential
I am attempting to compile gcc 4.4.0 on opensolaris 2009.6
Currently in the box (which is a AMD 64bit machine), I have the gcc 3.4.6 installed.
I unpacked the gcc 4.4.0 tarball.
I set the following env variables:
export CXX=/usr/local/bin/g++
export CC=/usr/local/bin/gcc
Then I ran "configure && make" and this is the error message that I got:
checking for i386-pc-solaris2.11-gcc... /export/home/me/wd/gcc/gcc-4.4.0/host-i386-pc-solaris2.11/gcc/xgcc -B/export/home/me/wd/gcc/gcc-4.4.0/host-i386-pc-solaris2.11/gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -m64
checking for suffix of object files... configure: error: in `/export/home/me/wd/gcc/gcc-4.4.0/i386-pc-solaris2.11/amd64/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
Anyone has any suggestion as to how to work around this error message?
/Edit:
Content of the config.log is posted here: link text
Normally the GCC build is bootstrapped, i.e. first it uses the system compiler to build GCC C compiler, and then it uses the freshly built compiler to recompile GCC once again (and then even once more time again). The configure line shows that it is not the system compiler but the already-built GCC compiler which is used for configure test there.
Since it fails, the problem is that the freshly-built GCC is somehow "stillborn" here. If config.log will not help you, I'd suggest to ask at gcc-help#gcc.gnu.org.
EDIT: Ah-ha, I think it is the assembler. You are using GNU assembler, but the unsupported options look like they were meant for Sun assembler. This should be solved by adding --with-gnu-as configure option (and then possibly having to specify its path explicitly with --with-as=/usr/gnu/bin/as)
You can also take a look at Solaris-specific GCC build instructions.
There's a readily available build for gcc4, which you can try updating. Its current version is 4.3.3. To get started, install pkg-get from OpenCSW and check out the build from the subversion repository:
svn co https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/gcc4/trunk/ gcc4
cd gcc4
gmake package