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 "Apache>2.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.
