I have attempted to build several readily available open source packages (among them zlib 1.2.1 and OpenSSL 0.9.7d) with the -static-libgcc option passed to gcc, in order to avoid the dependency on libgcc_s.so.1 and the problems it can cause. GCC accepts this argument, but appears to ignore it silently, as ldd still shows the libgcc_s dependency in any binary (be it a library or an executable) built by gcc that had this dependency prior to supplying the -static-libgcc option. The test machine is running Solaris 9 (SunOS 5.9), patch level 112233-08, on an UltraSPARC IIe. The compiler used is the gcc 3.3.2 package for Solaris 9 from http://www.sunfreeware.com/. I have not yet attempted to build gcc 3.3.3 from source, but I can find no mention of this in the changelog. I also cannot find an existing bug report for this. I am not a compiler expert, so if I have left out any information vital to reproducing this problem, please email me. I will do my best to provide any required information, and I can also supply a login on a Solaris 9 machine for debugging purposes.
We need more information: which dev tools do you use (GNU binutils or Sun tools)? Can you reproduce the problem with any C source file? What options does the compiler pass to the linker (use --verbose)? What options were used to build the compiler (use -v)?
Slightly different environment but same problem here: The generated .so's depend on libgcc_s.so.1 and so do the executables linked against them even if -static-libgcc is used in all builds; no error or warning message is issued. OS: SunOS tristan 5.8 Generic_117000-03 sun4u sparc SUNW,Sun-Blade-1500 GCC 3.3.2 for Solaris 8 from sunfreeware.com: ,---- |Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/specs |Configured with: ../configure --with-as=/usr/ccs/bin/as |--with-ld=/usr/ccs/bin/ld --disable-nls --disable-libgcj |--enable-languages=c,c++ |Thread model: posix |gcc version 3.3.2 `---- Sample from build transcript of OpenSSL 0.9.7d: ,---- |gcc -I. -I.. -I../include --verbose -static-libgcc -fPIC -DOPENSSL_THREADS |-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -O3 |-fomit-frame-pointer -Wall -DB_ENDIAN -DBN_DIV2W -c cryptlib.c |Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/specs |Configured with: ../configure --with-as=/usr/ccs/bin/as |--with-ld=/usr/ccs/bin/ld --disable-nls --disable-libgcj |--enable-languages=c,c++ |Thread model: posix |gcc version 3.3.2 | /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/cc1 -quiet -v -I. -I.. |-I../include -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=2 -Dsparc |-D__sparc__ -D__sparc -D__GCC_NEW_VARARGS__ -Acpu=sparc -Amachine=sparc |-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 |-DB_ENDIAN -DBN_DIV2W cryptlib.c -quiet -dumpbase cryptlib.c -auxbase cryptlib |-O3 -Wall -version -fPIC -fomit-frame-pointer -o /var/tmp//ccFMujIS.s |GNU C version 3.3.2 (sparc-sun-solaris2.8) | compiled by GNU C version 3.3.2. |GGC heuristics: --param ggc-min-expand=65 --param ggc-min-heapsize=65536 |ignoring nonexistent directory "NONE/include" |ignoring nonexistent directory "/usr/local/sparc-sun-solaris2.8/include" |#include "..." search starts here: |#include <...> search starts here: | . | .. | ../include | /usr/local/include | /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/include | /usr/include |End of search list. | /usr/ccs/bin/as -V -Qy -s -K PIC -o cryptlib.o /var/tmp//ccFMujIS.s |/usr/ccs/bin/as: Sun WorkShop 6 2003/12/18 Compiler Common 6.0 Patch 114802-02 `----
Please read the docs, there are cases in which -shared-libgcc is automatically passed to the linker. Does the problem occur with every single C file? If no, I suspect you just hit such a case.
The manual only mentions (as far as I can tell from searching it for the string "shared-libgcc") that the G++ and GCJ drivers activate -shared-libgcc because it is needed for exception handling (OpenSSL's Makefile however does not contain the string "++"). The manual also says that one needs to link plain C stuff that is supposed to handle exceptions with the G++ or the GCJ driver or with an explicit -shared-libgcc but does not say anything about adding it automagically. (And I don't find the string "shared-libgcc" in the transcript of a build run with CFLAGS containing --verbose). It is true however, that the inclusion of libgcc_s.so.1 does not happen for every C source file. Meanwhile I have implemented the solution proposed in http://www.mail-archive.com/openssl-dev@openssl.org/msg16142.html and with that GCC 3.3.2 will build .so's without dependencies to libgcc_s. So GCC /can/ build OpenSSL (and probably others) that way, although I am not sure that this measure will not break things at runtime later. Is this risky, and if so, to what degree?
> The manual only mentions (as far as I can tell from searching it for the > string "shared-libgcc") that the G++ and GCJ drivers activate -shared-libgcc > because it is needed for exception handling (OpenSSL's Makefile however does > not contain the string "++"). The manual also says that one needs to link > plain C stuff that is supposed to handle exceptions with the G++ or the GCJ > driver or with an explicit -shared-libgcc but does not say anything about > adding it automagically. There are also these lines: If, instead, you use the GCC driver to create shared libraries, you may find that they will not always be linked with the shared `libgcc'. If GCC finds, at its configuration time, that you have a GNU linker that does not support option `--eh-frame-hdr', it will link the shared version of `libgcc' into shared libraries by default. Granted, there is an inaccuracy, this should be "that you have a linker". > (And I don't find the string "shared-libgcc" in the transcript of a build run > with CFLAGS containing --verbose). It is true however, that the inclusion of > libgcc_s.so.1 does not happen for every C source file. -shared-libgcc is automatically activated for shared libraries unless you pass -static-libgcc. I think you should hack the OpenSSL makefile so as to pass -static-libgcc when creating the shared object. > Meanwhile I have implemented the solution proposed in > > http://www.mail-archive.com/openssl-dev@openssl.org/msg16142.html > > and with that GCC 3.3.2 will build .so's without dependencies to libgcc_s. So > GCC /can/ build OpenSSL (and probably others) that way, although I am not sure > that this measure will not break things at runtime later. Is this risky, and > if so, to what degree? I think this is safe if OpenSSL is not compiled with -fexceptions.
-static-libgcc works for me (when passed at link time), both with executables and shared objects, as of GCC 3.3.2 on Solaris 8.
*** Bug 27276 has been marked as a duplicate of this bug. ***