This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.0 Release Criteria
- To: mark at codesourcery dot com, rth at cygnus dot com
- Subject: Re: GCC 3.0 Release Criteria
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Thu, 27 Apr 2000 10:45:42 -0400 (EDT)
- Cc: gcc at gcc dot gnu dot org, geoffk at cygnus dot com, libc-hacker at sourceware dot cygnus dot com
> From: Richard Henderson <rth@cygnus.com>
>
> > Also, what negative consequences are likely?
>
> Getting the shared library installed in a place that gets searched by
> ld.so is hard. It's one of the main reasons we've put this off for so
> long. (Actually, didn't we try a libgcc.so in the deep dark past, ran
> into issues with this, and gave up?)
>
> Making sure that we've got the right version of libgcc is hard. Some
> of the uncertainty can be avoided by using symbol versioning, but that
> is only available on (some late version of) Solaris and Linux (glibc 2.1+).
> r~
Just to clarify, we are talking about installing libgcc.so in addition
to libgcc.a because people may want to statically link, right?
So for shared libs, we couple the user's library with libgcc.so and
with static links of binaries we link against libgcc.a.
What about dynamic links of binaries? If I develop an app for solaris
or on linux with a version of gcc newer than the system one, I want to
link against libgcc.a but dynamically against libc to avoid having to
distribute libgcc.so. Will we (can we) make this the default behavior?
--Kaveh
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Qwest Internet Solutions