Can't find libgcc after building 1.4.1

[Douglas E. Engert]

Another way around this is to use the static version of libgcc.

This can be done by default by changing the specs file for example:

  ./lib/gcc-lib/sparc-sun-solaris2.9/3.3.2/specs

The patch makes the static version the default. You can still
use the dynamic version if needed. We have done this for years
with Kerberos, OpenSSL and OpenSSH without problems.

http://www.mail-archive.com/openssl-dev@openssl.org/msg16145.html

Gcc-3.1 introduced -shared-libgcc and -static-libgcc
But when building shared libs, it wants to include the
libgcc_s shared version, even when not needed by default.
This causes problems when trying to build shared libs,
as they will need the extra libgcc_s.so.n.n when it really
is not needed.



Rainer Orth wrote:

> Tom Yu <tlyu at MIT.EDU> writes:
> 
> 
>>It might be more correct to put LDFLAGS in the definition of
>>LDCOMBINE.  I'm somewhat puzzled that gcc isn't adding an RPATH to
>>libgcc_s.so.1 itself.  Could this be a bug or configuration problem in
>>gcc itself?
> 
> 
> No, the GCC developers claim for years that this is a feature, not a bug ;-(
> Cf. http://gcc.gnu.org/faq.html#rpath for details.
> 
> 	Rainer
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: specs.patch
Url: http://mailman.mit.edu/pipermail/kerberos/attachments/20060214/5f760c64/attachment.bat