I'm trying to build Apache with gcc but with the configuration I'm using Apache gets dynamically linked with libgcc by default. This is a big problem since I'm building Apache on one machine and delivering it to systems that don't have gcc (and thus libgcc installed). For this reason I need to be able to build Apache without the dynamic libgcc linkage. I tried configuring Apache with the '-static-libgcc' gcc flag but this doesn't seem to have any effect on the resulting binary. I added the flag to both CFLAGS and LDFLAGS during configure. Here's the build procedure I'm using: export PATH=/opt/local/gcc/4.0/bin:$PATH:/usr/ccs/bin:/opt/sfw/bin CC=gcc CFLAGS="-mcpu=v9 -m64 -static-libgcc" LDFLAGS="-static-libgcc" \ ./configure --prefix=/home/aspa/tmp/h4 \ --enable-ssl --with-ssl=/opt/openssl/kb3404 \ --enable-proxy=shared --enable-proxy-http=shared \ --enable-cache=shared --enable-disk-cache=shared \ --enable-usertrack=shared --enable-rewrite gmake gmake install top_dir=/home/aspa/tmp/h4
A workaround I found is to force static libgcc linkage in gcc configuration (specs file). This can be done by applying the following patch to gcc 4.0.2 specs file: 60c65 < %{static|static-libgcc:-lgcc -lgcc_eh}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc -lgcc_eh}% {shared-libgcc:-lgcc_s -lgcc}}%{shared:-lgcc_s}}} --- > %{static|static-libgcc:-lgcc -lgcc_eh}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc -lgcc_eh}% {shared-libgcc:-lgcc -lgcc_eh}}%{shared:-lgcc -lgcc_eh}}}
What can be changed in the httpd build system which would make a difference? It looks like libtool is passing through -static-libgcc to the compiler OK, so I can't see what is being done wrong. Please attach the output of: rm httpd; make LTFLAGS= if you think the flag is not being passed to gcc correctly.
Created attachment 17390 [details] typescript from a build here's a typescript from a full build. after the build i executed the suggested commands: rm httpd gmake LTFLAGS=
(In reply to comment #2) > What can be changed in the httpd build system which would make a difference? > > It looks like libtool is passing through -static-libgcc to the compiler OK, so I > can't see what is being done wrong. > > Please attach the output of: > > rm httpd; make LTFLAGS= > > if you think the flag is not being passed to gcc correctly. i ran a full build and after the build finished ran the commands you suggested. The libgcc dependency still seems to exist by checking ldd .libs/httpd ldd /home/aspa/tmp/h4/bin/httpd # installation directory
As you can see, the flag is being passed through correctly by the httpd build system, so there's nothing going wrong from this end: ... gcc -pthreads -mcpu=v9 -m64 -static-libgcc ... I'd suggest checking whether the libgcc dependency comes from any of the shared libraries which were built (using ldd); if so I'd suggest also passing --disable-shared to configure.
(In reply to comment #5) In the build typescript the '-static-libgcc' was being passed to libtool, not directly to gcc in all cases except the final httpd binary link. Could it be possible that libtool doesn't pass this flag to gcc? The only external dependencies in the build should be OS libraries and OpenSSL. 'ldd .libs/httpd' shows that the binary has been dynamically linked with only OS libraries and libgcc in addition to Apache provided libraries: libaprutil-0.so.0 => /home/aspa/tmp/h4/lib/libaprutil-0.so.0 libexpat.so.0 => /home/aspa/tmp/h4/lib/libexpat.so.0 libapr-0.so.0 => /home/aspa/tmp/h4/lib/libapr-0.so.0 libsendfile.so.1 => /usr/lib/64/libsendfile.so.1 librt.so.1 => /usr/lib/64/librt.so.1 libm.so.1 => /usr/lib/64/libm.so.1 libsocket.so.1 => /usr/lib/64/libsocket.so.1 libnsl.so.1 => /usr/lib/64/libnsl.so.1 libresolv.so.2 => /usr/lib/64/libresolv.so.2 libpthread.so.1 => /usr/lib/64/libpthread.so.1 libdl.so.1 => /usr/lib/64/libdl.so.1 libc.so.1 => /usr/lib/64/libc.so.1 libgcc_s.so.1 => (file not found) libgcc_s.so.1 => (file not found) libgcc_s.so.1 => (file not found) libaio.so.1 => /usr/lib/64/libaio.so.1 libmp.so.2 => /usr/lib/64/libmp.so.2 libthread.so.1 => /usr/lib/64/libthread.so.1 /usr/platform/SUNW,UltraAX-i2/lib/sparcv9/libc_psr.so.1 The OpenSSL installation tree used in the build only contained static versions of the libraries so OpenSSL is statically linked with Apache. Checking dynamic dependencies on shared objects shows that all the shared objects in the build tree have been dynamically linked with libgcc. Here's a list of objects I checked: # gfind . -iregex '.*\.so' ./modules/proxy/.libs/mod_proxy.so ./modules/proxy/.libs/mod_proxy_connect.so ./modules/proxy/.libs/mod_proxy_ftp.so ./modules/proxy/.libs/mod_proxy_http.so ./modules/metadata/.libs/mod_usertrack.so ./modules/experimental/.libs/mod_cache.so ./modules/experimental/.libs/mod_disk_cache.so ./srclib/apr-util/xml/expat/lib/.libs/libexpat.so ./srclib/apr-util/.libs/libaprutil-0.so ./srclib/apr/.libs/libapr-0.so
> In the build typescript the '-static-libgcc' was being passed to libtool, not directly to gcc in all cases > except the final httpd binary link. Could it be possible that libtool doesn't pass this flag to gcc? Yes, that is quite possible. I notice you are passing -m64 in CFLAGS; that is not a good idea either. Here is what I would try if the LDFLAGS trick did not work: CC="gcc -mcpu=v9 -m64 -static-libgcc" ./configure ...etcetc if that does not work either please report the issue to bug-libtool@gnu.org, the httpd build system is driving libtool correctly AFAICT; LDFLAGS is also propagated through the buildsystem correctly, so I can't see any httpd bug that can be fixed.
(In reply to comment #7) Using your suggestion of including the gcc configure flags in the CC variable instead of CFLAGS fixes this issue, thanks very much! In general, is it recommended to include compiler flags in CC and not CFLAGS? I would argue that from the user's point of view this is, in fact, an Apache bug since libtool has been bundled as part of Apache. The user is not typically aware of all the different third party components that have been bundled in a particular piece of software that he's using. However, I can understand your point of view since I'm in software development myself. It's a bug in a third party component, but it does affect Apache users as well. If this report is closed for Apache, then there won't be any way of tracking when the issue actually gets fixed and it won't appear in future release notes either. If you still do not consider this as an Apache issue, I would appreciate some help in reporting it as a libtool bug. - Which version of libtool is used in Apache 2.0.55? - Is it an unmodified version of libtool? - Since I don't know much about libtool I'm a bit uncertain about how to properly formulate the report. Would 'Libtool v.X does not properly pass the '-static-libgcc' flag in CFLAGS to gcc' be correct way to formulate the problem?
Given the workaround I'm going to close this report; I've mailed the libtool list asking about whether the behaviour is expected or not. It is sometimes necessary to include compiler flags in CC but usually only ones which affect the ABI; -static-libgcc should not really count as such.