httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From harald deppeler <har...@deppeler.org>
Subject Re: httpd-2.0.46 needs gcc_s? (on solaris 8)
Date Thu, 05 Jun 2003 21:33:19 GMT
Ok, I tried the CFLAGS=-static-libgcc trick, it didn't work for me.

Interpreting the compile log I gather that the c flag is carried through
from the configure stage up until to the final linking, however, it does
not achieve the desired result (see excerpt at the end of this mail). This
would probably be libtool's fault, then, I suppose.  We're using version
1.4 - maybe we should upgrade?

On Thu, Jun 05, 2003 at 04:01:27PM -0400, Jeff Trawick wrote:
> see also http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20447

Aha.
I'm not alone ... :-)

> seems like you could copy libgcc_s to Apache's lib directory... Apache's 
>   bin/envvars file already updates LD_LIBRARY_PATH to include that directory
> 
> or install it anywhere, and if isn't in the dynamic loader's default 
> search path, update Apache's bin/envvars file to include that directory 
> in LD_LIBRARY_PATH
> 
>  >Configure Apache in such a way that it doesn't
> > use libgcc_s? How would we do the latter (preferred)?
> 
> The stuff that needs libgcc_s isn't anything we've done explicitly but 
> instead the code generated by gcc.  (Apparently now they use a shared 
> library instead of a static one, but this is the same old story that 
> many people have seen on AIX and Solaris in the past, where we changed a 
> few lines of code in a DSO and it would no longer load because it 
> referenced some floating point routines which were unresolved.)
> 
> Maybe the gcc documentation or developers can provide some hints?  I dunno.

http://www.gnu.org/software/gcc/gcc-3.0/libgcc.html states a little bit.
I'm not sure whether I fully understand it, but somehow it seems to mean
that certain gcc compiled binaries cannot be rolled out stand-alone but
will need a shared libgcc. (...grumble...)

> Back to the big picture...  we reference libgcc_s without doing anything 
> explicitly...  conceivably any other packages you build with the same 
> compiler could do that too.  That speaks in favor of putting it in a 
> standard location (e.g., /usr/local/lib) on the machines you roll Apache 
> out to and making sure it is in the dynamic loader's search path.

I guess I'll follow your recommendation. Install libgcc_s.so in
/usr/local/lib and adapt the systemwide ld path accordingly (using
Solaris' crle(1)).

Still bugs me that other packages (BIND, Sendmail, ... ) we build on that
machine don't seem to reference libgcc_s ... and the 2.0.44 Apache did
not, either. I'll check whether we were really using the same version
of gcc for packaging 2.0.44.

Thanks for the help so far!

cu - Harry

[...]
/bin/bash /export/home/package/httpd_cache/httpd-2.0.46/srclib/apr/libtool
--silent --mode=link gcc  -pthreads  -static-libgcc  -DSOLARIS2=8
-D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DAP_HAVE_DESIGNATED_INITIALIZER
-I/export/home/package/httpd_cache/httpd-2.0.46/srclib/apr/include
[ ... lots of includes ... ]
-I/export/home/package/httpd_cache/httpd-2.0.46/modules/dav/main
-export-dynamic
-L/export/home/package/httpd_cache/httpd-2.0.46/srclib/apr-util/xml/expat/lib
-o httpd  modules.lo  modules/aaa/mod_access.la
modules/cache/mod_file_cache.la modules/experimental/mod_cache.la
modules/experimental/mod_disk_cache.la
modules/experimental/mod_mem_cache.la
modules/loggers/mod_log_config.la modules/metadata/mod_setenvif.la
modules/proxy/mod_proxy.la modules/proxy/mod_proxy_connect.la
modules/proxy/mod_proxy_ftp.la modules/proxy/mod_proxy_http.la
modules/http/mod_http.la modules/generators/mod_status.la
server/mpm/prefork/libprefork.la server/libmain.la os/unix/libos.la
/export/home/package/httpd_cache/httpd-2.0.46/srclib/pcre/libpcre.la
/export/home/package/httpd_cache/httpd-2.0.46/srclib/apr-util/libaprutil-0.la
/export/home/package/httpd_cache/httpd-2.0.46/srclib/apr-util/xml/expat/lib/libexpat.la
/export/home/package/httpd_cache/httpd-2.0.46/srclib/apr/libapr-0.la
-lrt -lm -lsocket -lnsl -lresolv -ldl 
[...]

# ldd ./httpd-2.0.46/.libs/httpd
[...]
        libc.so.1 =>     /usr/lib/libc.so.1
        libgcc_s.so.1 =>         (file not found)
        libgcc_s.so.1 =>         (file not found)
        libgcc_s.so.1 =>         (file not found)
[...]
        /usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1
#


Mime
View raw message