I want to build my cross compile tool chain, I build it successful.
It can use normally, but when I move it, it cannot work!!
It print error while loading shared libraries: libcloog-isl.so.3, libcloog-isl is not install in my host.
I configure the gcc with --disable-shared, but when I run ldd to the cc1 in my cross compile tool chain, I found that ppl, gmp, moc, libgcc_s and some other link to my host library. why it cannot static link into cc1 when I use --disable-shared.
I found that Sourcery CodeBench's tool chain can run anywhere, its cc1 not link my host library.
What should I do to static link in cc1 instead of dynamic link host library?
You may already be aware that the ld command (as well as gcc) will accept the -static option, but you may also need to use -static-libgcc and/or -static-libstdc++ to make sure you are linking statically to all libraries.
Related
**Edit: Found my problem. As explained by the following answer, I was not actually doing any linking when making the static library. Instead, I made a shared library and linked libstdc++ statically.
Compile a static library link with standard library (static)**
I am trying to create a method to use c++11 on an ancient arm platform running kernel (2.6.37). Unfortunately the latest cross compile our BSP contains is GCC 4.5.3, which does not support all the c++11 utilites we need.
Initially I tried to use old versions of crosstool-ng to build a cross compiler, but the older versions were too broken. The newer versions did not support the 2.6.37 kernel. I was able to complete one build, however the g++ binary was not built, making the whole endeavor useless (I did check that c++ was enabled in the menuconfig).
Thus my last option was to build gcc natively at version 4.9.4 and create a statically linked library to have my gcc 4.5.3 cross compiler link against. This seems to work for the most part. I create my library on the target with the following:
g++ -std=c++11 --static -c main2.cpp
ar -cvq libmain2.a main2.o
I then copy over the files and try build on the host machine with gcc 4.5.3 and get the following:
arm-angstrom-linux-gnueabi-g++ simple.cpp -lmain2 -L.
(I cleaned up some of the output)
undefined reference to `std::_Hash_bytes(void const*, unsigned int, unsigned int)'
undefined reference to
std::__throw_regex_error(std::regex_constants::error_type)'
However, when I use nm, I get the following:
$ arm-angstrom-linux-gnueabi-nm libmain2.a | grep Hash_bytes
U _ZSt11_Hash_bytesPKvjj
U _ZSt11_Hash_bytesPKvjj
$ arm-angstrom-linux-gnueabi-nm libmain2.a | grep throw_regex
U _ZSt19__throw_regex_errorNSt15regex_constants10error_typeE
U _ZSt19__throw_regex_errorNSt15regex_constants10error_typeE
Does anyone know what the heck is going on? Unfortunately we need to be able to use our cross compiler on the host system for most work, but we are also needing to integrate this specific library which uses c++11.
Also note that if I take out the regex and hash functionality from my code but leave other c++11 concepts like nullptr, type inference, delegation etc, the code compiles and runs on the target fine.
Edit: Okay, so after a little more investigation, it looks like the functions _Hash_bytes and __throw_regex_error are not being statically linked into the static library. I guess I need to know why this is the case in order to fix the issue.
I'm working through a text on linking, and wanted to work along with some examples in said text.
To better understand whats going on when I invoke the gcc driver, I was looking into doing all the compilation old-school by hand;
preprocessing using cpp
compiling with cc1
assembling with as
linking using ld
Unfortunately, on my Mac I don't seem to be able to reference cc1directly (no listing of cc1 in man). What are my options?
Read some material about GCC internals. First the wikipage on GCC. Then, you could play with the MELT probe (you may want a Linux system to use it).
Then read the GCC manual. And the GCC resource center
Use gcc -v -Wall to compile, it will show what cc1 is running (and -Wall is always useful). So try compiling with gcc -v -Wall hello.c -o helloworld.bin
the cc1 program don't sit in your PATH or in /usr/bin/ but -on my system- in /usr/lib/gcc/x86_64-linux-gnu/4.8/cc1
The command gcc -print-prog-name=cc1 will tell you which cc1 is used by your gcc. See GCC debugging options for more.
The preprocessing is now inside cc1.
The gcc program is just a driver, starting cc1 (which does most of the compiling work), then as, ld etc...
The MELT site contains some documentation, and some slides explaining GCC, which you could find interesting. MELT is a domain specific language to extend GCC.
See also the picture on http://starynkevitch.net/Basile/gcc-melt/cc1-internals.svg and the below picture
picture from http://starynkevitch.net/Basile/gcc-melt/gcc-MELT-inside.png, done by me, CC BY SA
The cc1 is producing a .s assembly file; the as (started by gcc) is transforming it into .o. The ld linker (started by gcc) will produce a library or an executable.
PS. I have a Linux system, but things are very similar on MacOSX.
reference on linking
A good book about linking is Levine's Linkers & loaders book.
PS. MELT is obsolete in 2021, but I am working on the Bismon static source code analyzer and on RefPerSys (which generates C++ code).
For reference, I installed gcc-10 with brew on my macOS (Catalina).
While cc1 is not directly accessible (via PATH), it can be found in
/usr/local/Cellar/gcc/10.2.0/libexec/gcc/x86_64-apple-darwin19/10.2.0
If you are lost, try gcc -v and from the verbose information you may find where your cc1 is.
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.
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/
I have a shared library (*.so) created using Real View Compiler Tools (RVCT 3.2) on windows target. Then I try to link this *.so file with my application using gcc on linux system.
What is the gcc option to link this shared library with my application linux?
My question is, is the -shared option, which is used as
gcc -shared myfile.so
..., used to create the SO file or to link the SO file? I believe it creates something like:
gcc -lmyfile.so
Is this enough? Or is there any other switch to tell the linker that it's a dynamic library (shared object)?
What worked for me was:
gcc -L. -l:myfile.so
gcc -lmyfile should be enough (provided that your library is named libmyfile.so). The linker searches for shared objects when possible and AFAIK prefers them.