Re: httpd-2.0.46 needs gcc_s? (on solaris 8)
On Thu, Jun 05, 2003 at 04:01:27PM -0400, Jeff Trawick wrote: 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 This works just fine. Allows us to make a self-contained Apache package. The admin won't even have to adjust the system-wide shared library path. Thanks for all the help and advice. - Harry
httpd-2.0.46 needs gcc_s? (on solaris 8)
We're upgrading from 2.0.44 to 2.0.46 and have noticed that the httpd binary now seems to need libgcc_s. # ldd /some/path/httpd libaprutil-0.so.0 = /some/path/lib/libaprutil-0.so.0 libexpat.so.0 = /some/path/lib/libexpat.so.0 libapr-0.so.0 = /some/path/lib/libapr-0.so.0 librt.so.1 =/usr/lib/librt.so.1 libm.so.1 = /usr/lib/libm.so.1 libsocket.so.1 =/usr/lib/libsocket.so.1 libnsl.so.1 = /usr/lib/libnsl.so.1 libresolv.so.2 =/usr/lib/libresolv.so.2 libdl.so.1 =/usr/lib/libdl.so.1 libpthread.so.1 = /usr/lib/libpthread.so.1 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) libaio.so.1 = /usr/lib/libaio.so.1 libmp.so.2 =/usr/lib/libmp.so.2 libthread.so.1 =/usr/lib/libthread.so.1 /usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1 # Our build systems have gcc (3.2.1) and other development tools installed. Our roll-out systems are stripped down and contain no such libraries, compilers or tools. What would be the recommended way to roll out our 2.0.46 package? Include libgcc_s with it? Roll out an Apache2.0.44 supporting package including the necessary lib(s)? Configure Apache in such a way that it doesn't use libgcc_s? How would we do the latter (preferred)? Cheers - Harry
Re: httpd-2.0.46 needs gcc_s? (on solaris 8)
Build it with CFLAGS=-static-libgcc On Thu, 2003-06-05 at 05:18, harald deppeler wrote: We're upgrading from 2.0.44 to 2.0.46 and have noticed that the httpd binary now seems to need libgcc_s. # ldd /some/path/httpd libaprutil-0.so.0 = /some/path/lib/libaprutil-0.so.0 libexpat.so.0 = /some/path/lib/libexpat.so.0 libapr-0.so.0 = /some/path/lib/libapr-0.so.0 librt.so.1 =/usr/lib/librt.so.1 libm.so.1 = /usr/lib/libm.so.1 libsocket.so.1 =/usr/lib/libsocket.so.1 libnsl.so.1 = /usr/lib/libnsl.so.1 libresolv.so.2 =/usr/lib/libresolv.so.2 libdl.so.1 =/usr/lib/libdl.so.1 libpthread.so.1 = /usr/lib/libpthread.so.1 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) libaio.so.1 = /usr/lib/libaio.so.1 libmp.so.2 =/usr/lib/libmp.so.2 libthread.so.1 =/usr/lib/libthread.so.1 /usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1 # Our build systems have gcc (3.2.1) and other development tools installed. Our roll-out systems are stripped down and contain no such libraries, compilers or tools. What would be the recommended way to roll out our 2.0.46 package? Include libgcc_s with it? Roll out an Apache2.0.44 supporting package including the necessary lib(s)? Configure Apache in such a way that it doesn't use libgcc_s? How would we do the latter (preferred)? Cheers - Harry -- Brian Akins [EMAIL PROTECTED] CNN Internet Technologies
Re: httpd-2.0.46 needs gcc_s? (on solaris 8)
harald deppeler wrote: We're upgrading from 2.0.44 to 2.0.46 and have noticed that the httpd binary now seems to need libgcc_s. ugh see also http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20447 # ldd /some/path/httpd libgcc_s.so.1 = (file not found) libgcc_s.so.1 = (file not found) libgcc_s.so.1 = (file not found) Our build systems have gcc (3.2.1) and other development tools installed. Our roll-out systems are stripped down and contain no such libraries, compilers or tools. What would be the recommended way to roll out our 2.0.46 package? Include libgcc_s with it? Roll out an Apache2.0.44 supporting package including the necessary lib(s)? 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. 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.
Re: httpd-2.0.46 needs gcc_s? (on solaris 8)
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 #
Re: httpd-2.0.46 needs gcc_s? (on solaris 8)
On Thu, 5 Jun 2003, harald deppeler wrote: Ok, I tried the CFLAGS=-static-libgcc trick, it didn't work for me. Did you verify that libtool passed the flag to the linker? You can achieve that by removing --silent from the respective Makefile. - Sascha
