Compiling / linking with -nostdlib seems to prevent static initialization, even if I add my own crti.s and crtn.s with .init/.fini sections.
Are there workarounds to make g++ generate static initialization code that is inserted in .init or that I can call manually?
This is what I tried:
g++ -o test.o -c -fno-use-cxa-atexit test.cc # has _start (entry point)
# that calls _init and _main
as -o crti.o crti.s # has _init in section .init
as -o crtn.o crtn.s
g++ -o test ./crti.o test.o -nodefaultlibs -nostartfiles ./crtn.o
-nodefaultlibs alone includes static initialization code and call, but forces use of libc-_start/_init.
-nodefaultlibs -nostartfiles allows me to use my own _start / _init, but does not include code or call to static initialization.
From gcc linker docs,
-nostdlib
Do not use the standard system startup files or libraries when
linking. No startup files and only the libraries you specify will be
passed to the linker, and options specifying linkage of the system
libraries, such as -static-libgcc or -shared-libgcc, are ignored.
Hence use,
-nodefaultlibs
Do not use the standard system libraries when linking. Only the libraries you specify will be passed to the linker, options specifying linkage of the system libraries, such as -static-libgcc or -shared-libgcc, will be ignored. The standard startup files are used normally, unless -nostartfiles is used. The compiler may generate calls to memcmp, memset, memcpy and memmove. These entries are usually resolved by entries in libc. These entry points should be supplied through some other mechanism when this option is specified.
Also try,
g++ -Wl, -static
-Wl passes the next command on to the linker
-static On systems that support dynamic linking, this prevents linking with
the shared libraries. On other systems, this option has no effect.
Related
In GCC, if I compile something into a shared library with GCC with g++ -shared func.cpp -o libfunc.so -fPIC, internal function calls to global symbols go through GOT in this generated shared library file. But if I compile with g++ func.cpp -o libfunc.so -mcmodel=large, it will not generate GOT but instead relocate by patching with R_X86_64_64 style relocation directly.
I want this behavior for executables as well. If I compile an executable with g++ main.cpp libfunc.so -o a.out, GCC will generate GOT for any function call from main.cpp to one defined in libfunc.so. I don't want this behavior. I want R_X86_64_64 style relocation. How can I achieve that?
Executables are compiled with -fPIE by default in modern distros for security reasons. To get old behavior add -no-pie to CFLAGS/CXXFLAGS.
I am new to C++ compiling/linking.
I am trying to link all libraries statically with gcc, I tried using LDFLAGS=-static but did not work. Error message showed:
/bin/sh ./libtool --tag=CXX --mode=link /home/dizhang/lib/hdf5/bin/h5c++ -g -O2 -L/home/dizhang/lib/blitz/lib -L/home/dizhang/lib/libconfig/lib -o angora src/libangora.la -lblitz -lconfig++
libtool: link: /home/dizhang/lib/hdf5/bin/h5c++ -g -O2 -o angora -L/home/dizhang/lib/blitz/lib -L/home/dizhang/lib/libconfig/lib src/.libs/libangora.a -L/bgsys/drivers/V1R2M2/ppc64/comm/lib64 -L/bgsys/drivers/V1R2M2/ppc64/comm/lib -L/bgsys/drivers/V1R2M2/ppc64/spi/lib -lpthread -lm /home/dizhang/lib/blitz/lib/libblitz.a /bgsys/drivers/V1R2M2/ppc64/comm/lib/libmpichcxx-gcc.so /bgsys/drivers/toolchain/V1R2M2_base/gnu-linux/powerpc64-bgq-linux/lib/libstdc++.so /bgsys/drivers/V1R2M2/ppc64/comm/lib/libmpich-gcc.so /bgsys/drivers/V1R2M2/ppc64/comm/lib/libopa-gcc.so /bgsys/drivers/V1R2M2/ppc64/comm/lib/libmpl-gcc.so /home/dizhang/lib/libconfig/lib/libconfig++.a /bgsys/drivers/toolchain/V1R2M2_base-efix014/gnu-linux/powerpc64-bgq-linux/lib/libstdc++.so -Wl,-rpath -Wl,/bgsys/drivers/toolchain/V1R2M2_base-efix014/gnu-linux/powerpc64-bgq-linux/lib -Wl,-rpath -Wl,/bgsys/drivers/V1R2M2/ppc64/comm/lib -Wl,-rpath -Wl,/bgsys/drivers/toolchain/V1R2M2_base/gnu-linux/powerpc64-bgq-linux/lib -Wl,-rpath -Wl,/bgsys/drivers/toolchain/V1R2M2_base-efix014/gnu-linux/powerpc64-bgq-linux/lib -Wl,-rpath -Wl,/bgsys/drivers/V1R2M2/ppc64/comm/lib -Wl,-rpath -Wl,/bgsys/drivers/toolchain/V1R2M2_base/gnu-linux/powerpc64-bgq-linux/lib
/bgsys/drivers/toolchain/V1R2M2_base-efix014/gnu-linux/lib/gcc/powerpc64-bgq-linux/4.4.7/../../../../powerpc64-bgq-linux/bin/ld: attempted static link of dynamic object `/bgsys/drivers/V1R2M2/ppc64/comm/lib/libmpichcxx-gcc.so'
collect2: ld returned 1 exit status
I did some search and found that, telling Makefile -Wl -Bstatic may solve this problem, but how exactly I should change this in my Makefile?
I tried searching -Wl in Makefile but it was not in the text.
Thanks,
Di
Looks like you are trying to build HDF5 with MPI support on BGQ.
As long as you end up passing a ".so" version of a lib to gcc on BGQ -- you will see this error. You may need to check how you are passing MPI info to HDF5's configure script.
In my case (building another project that uses CMake) passing BGQ's MPI compiler wrappers to CMake always created a problem where it would try to link MPI using the shared libs instead of the static ones. To resolve this, I had to make sure to explicitly specify the ".a" variants of the MPI libs.
When I enable Link Time Optimization in GCC, the binaries produced become much larger. I expected GCC to be able to remove a lot of reduntant functions, and perform other optimizations otherwise impossible, so how come this makes the generated output grow?
Compiler flags:
-Os -c -fno-builtin -ffunction-sections -fdata-sections -flto -mcpu=cortex-m0 -mthumb
Linker flags:
-nostdlib -s -Xlinker --gc-sections -flto -mcpu=cortex-m0 -mthumb -T
Did you strip the binary after linking with -flto (it should be provided both at compilation and at link time)?
BTW, notice that the same optimization flags (-flto -Os) should be passed both at compile time and at link time. If you forgot -like you did- any of them at linking phase, LTO won't work! (When using make you want CC=gcc -flto -Os not CFLAGS= -flto -Os).
You did forgot -Os at link time, in addition of -flto; just passing -flto at link time without any optimizations is wrong: the LTO phase would "de-optimize" at most
I know that -flto adds a lot of sections in the ELF object files and executables (those sections contain the serialization of GCC internal representations like Gimple....). I guess (but have not checked) that the linking does not remove them.
Also, the main point of LTO is to inline accross several compilation units and this is expected to grow the code. So perhaps you should not use LTO in your particular case.
Most redundant functions are already removed (by the linker "GC" on sections) even without LTO.
BTW, you could use objdumpor readelfto find out.
Important thing for LTO is the working linker plugin support. Only with that GCC can make agressive unreachable code removal and other optimizaitons. Be sure you have plugin enabled linker (just try if LTO linking works with -fuse-linker-plugin)
using gcc 4.5.1 in a 64bit x86 machine,I first create a.o as following:
g++ -fPIC -c a.cc -o a.o
then try to create liba.so as following:
g++ -static-libstdc++ -shared -W1,-soname,liba.so -o liba.so.1.0.0 a.o
but failed, with the following information:
relocation R_X86_64_32S against `vtable for __gnu_cxx::stdio_filebuf >' can not be used when making a shared object; recompile with -fPIC
I try to recompile libstdc++ library,with -fPIC added,but it failed anyway
I would expect that the static libstdc++ library was not build with -fPIC, and therefore can't be linked into a shared library.
Theoretically you could put non-PIC compiled code into a dynamic library, but it wouldn't be sharable (each program using it would have to have its own copy) so it's often not implemented.
You're going to need to link against the shared C++ library, make your own library a static library, or else rebuild libstdc++ yourself and grab the .o files from the build directory.
There is a similar question about this topic on stackoverflow, which refers to an external site about static linking of libstdc++.
I've been trying to find the proper .a's and related flags for statically linking an app or SO under Linux. I know -static exists, but I can't use it as there's one specific SO I must link to.
To put it another way, I'm looking for the appropriate flags to statically link everything, except for a specific SO.
Thanks.
At my workplace we use -Bstatic and -Bdynamic but they are options to the linker ld. You can specify them with gcc using the -Wl option.
g++ -o app -Wl,-Bstatic -llib1 -llib2 -llib3 -Wl,-Bdynamic -llib4 app.o
Above shows command line for linking with lib1, lib2, and lib3 as static libraries and lib4 as a shared object library.