I am using buildroot to build a fresh gcc cross-compiler on a dedicated machine.
It worked fine, but I now need to run this gcc from another machine, on which I have not the same libc version :-(. Of course gcc then crashed.
Is it possible to build gcc statically using buildroot ?
You could try passing -static to the linker (via LDFLAGS), but be aware that full static linking is not supported by glibc anymore (resp. it needs a glibc build which supports static linking).
This is due to the fact that nss libraries (name server switch) will be loaded dynamically (unless you compile your own glibc - but that defeats the purpose of nss). This might be enough for you however to reduce dependencies against system libraries.
But I could assume that a statically linked gcc is fairly huge - this might result in long startup times.
If your objective is only to make a relocatable toolchain, statically link with expat, gmp, mpfr and mpc should enough. You can simply apply https://patchwork.ozlabs.org/patch/359841/
Related
My developing/producing environments are all CentOS-7.7.
In order to compile my program with gcc-8.3.0, I have installed "devtoolset-8" on my developing env, but it can not be used in the way same as gcc-4.8.5 that was shipped with CentOS7 oringinally.
Every time I need to compile a program, I must use "scl enable devtoolset-8 -- bash" to switch to gcc8 instead of gcc4.8.5.
When the program was deploying onto the producing-env, there is no gcc8, nor libstdc++.so.6.0.25, so it can not run.
I guess libstdc++.so.6.0.25 should be released with gcc8? I can neither install "devtoolset-8" on the producing-env, nor build gcc8 from source on the producing env.
The version of libstdc++ that can be installed from the official yum repo of CentOS, is libstdc++.so.6.0.19, hence my programs can not be loaded at the producing-env.
How to let such programs to run?
Thanks!
Pls forgive my Ugly English.
In order to not have to copy or ship a separate libstdc++.so but rather link statically (as suggested in a comment) against the C++ runtime, one can link C++ programs with -static-libstdc++ (also specifying -static-libgcc will also make sure that the program does not depend on a recent enough version of libgcc_s.so on the system - although that should rarely be a problem).
There can also be the issue of the target system having a version of glibc that is too old (relative to the build system). In that case, one could anyhow compile gcc of no matter how recent of a version on the older system, so that the resulting C++ executables as well as libstdc++ are linked against the older glibc. Linking C++ programs with -static-libstdc++ will again help to not depend on the program having to be able to find libstdc++.so at run-time.
Finally, the C++ program could also be linked with -static not depending on any dynamic libraries at all.
Using the How To Build GCC 4.8.2 ARM Cross-Compiler, I have installed and setup everything and it works just fine as mentioned in the post i.e., I was able to cross compile a simple C code. But, when I try to compile a simple GMP code, I get this error.
fatal error: gmp.h: No such file or directory
Compilation terminated
How should I fix this? My goal is to compile a gmp program. If possible, refer me to good tutorials.
Thanks!
If you want GMP compiled for the target system (ARM), you must compile it by itself using the newly built cross-compiler, not as a part of building GCC. GMP (along with MPFR, MPC, ISL, CLooG, etc.) being placed in the GCC toplevel source directory simply means that it gets compiled and linked for the cross-compiler you're building.
Since the cross-compiler will run on the host system, GMP will also be compiled for the host system, else linking the library would fail, and you wouldn't get a cross-compiler. It may sound silly, but there are reasons for doing it this way, such as buggy prebuilt packages provided by the package manager on the host system or merely to avoid installing those libraries on the host system when all you want is the cross-compilation toolchain.
According to the address-sanitizer home page it comes only with the gcc 4.8 or above. Isn't there anyway of using it with gcc 4.7?
No, there is no reliable way (to get ASAN before GCC 4.8). ASAN requires compiler support and is very intimately connected to your particular compiler (and version, and host and target systems, and specific configuration, etc...)
In other words, try to compile a recent GCC (that is, GCC 5.2 in july 2015; use that since ASAN did progress since 4.8 and you'll get more -fsanitize= options in recent versions of GCC) from its downloaded source code. See hints here & there. You should try some recent Linux distribution.
(on Linux or other POSIX systems, you don't need root privileges to configure, compile, and install gcc-mine-5 in $HOME/soft/; you need appropriate ../gcc-5.2/configure options, notably --prefix=$HOME/soft --program-suffix=-mine-5, then add $HOME/soft/bin/ in your PATH then run with CC=gcc-mine-5 e.g. for make)
I've installed GCC 4.6.3 into a non-system path on a Mac system and it works fine. However, GCC wants to use code from libgcc for all the binaries I compile, and running otool -L shows that these compiled programs look for libgcc_s.1.dylib in GCC's install path. I can override this by passing -static-libgcc, which just compiles the stuff needed into the binary and that's fine. The problem is this only seems to work with executables, not shared libraries. If I use GCC to compile some third-party lib I want to use in one of my programs as a .dylib, these libraries still look for libgcc_s.1.dylib in the local GCC install path even if I specify -static-libgcc! Needless to say, this is a problem as there's no guarantee that those libraries will find libgcc when run on some other system.
I tried this with ffmpeg. If I look at config.log, the -static-libgcc is most certainly being used. GCC is just not linking libgcc statically with the resulting dylibs. I even tried the -nostdlib, -nostartfiles and -nodefaultlibs options but they were ignored. Again, I checked config.log and they're definitely there!
I believe this is to do with throwing exceptions across the shared library boundary. This page says:
There are several situations in which an application should use the
shared libgcc instead of the static version. The most common of these
is when the application wishes to throw and catch exceptions across
different shared libraries. In that case, each of the libraries as
well as the application itself should use the shared libgcc.
Therefore, the G++ and GCJ drivers automatically add -shared-libgcc
whenever you build a shared library or a main executable, because C++
and Java programs typically use exceptions, so this is the right thing
to do.
The rest of that sections gives a possible workaround (it appears) and that is to use the GCC driver to link your shared library, however if the statically-linked library throws exceptions you'll probably get a Segmentation Violation.
my custom built gcc 4.6.0, installed in my home directory, on ubuntu 10.04, links the system libstdc++ instead of the custom built one, most of the time (as evidenced by ldd). to be more puzzling, using this newly built gcc, custom compiled openmpi libraries are linked correctly, and this is the only software i have compiled that behaves ok. does anybody have any explanation for this, or a workaround?
thanks
Isn't there an option to statically link the libstdc into the gcc when you configure it? --disable-shared if I understand how it works correctly. Worst case make another compile of gcc with that switch and see if you run into the issue.
I don't know why this isn't detailed more clearly on the GCC website for end-users. The GCC FAQ clearly states this is a common problem wrt libstdc++. Environment variables are troublesome. Wrapping the linker, nobody knows how to do that. Editing /etc/ld.so.conf isn't an option. Adding -Wl,-rpath everywhere, come on. The easiest solution is the specs file. For a typical 64-bit x86 Linux system, go into your custom gcc installation, in dirname `g++ -print-libgcc-file-name`and then run g++ -dumpspecs > specs. Edit that file, find the *link_command: section. After %(link_libgcc) add -rpath /home/user/bin/gcc-9/lib64 (of course use your own path). Or add the same rpath to end of *link: section. Alternatively, configure gcc with --with-specs='%{!static:%x{-rpath=/home/user/bin/gcc9/lib64} %x{-enable-new-dtags}}' . Enjoy your own C++ compiler that generates binaries that just work.
See also:
GCC specs file: how to get the installation path
Linking g++ 4.8 to libstdc++
How to configure libstdc++ with GCC 4.8?