This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.0 Release Criteria
- To: rth at cygnus dot com
- Subject: Re: GCC 3.0 Release Criteria
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Fri, 28 Apr 2000 11:03:11 -0400 (EDT)
- Cc: gcc at gcc dot gnu dot org, geoffk at cygnus dot com dot mark@codesourcery.com
> From: Richard Henderson <rth@cygnus.com>
>
> > 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?
>
> This is a sticky problem, and I think the answer is no. Primarily,
> how do you know that your libgcc is newer that your user's?
>
> For Solaris this is easier -- the system libraries do not use libgcc,
> so it's relatively easy to create an application that does not have
> multiple libgcc problems. Assuming your application itself does not
> make heavy use of dsos. While I still think we should not make a
> static link to libgcc.a the default, it's easy to do on the commandline.
> We might even add a --static-libgcc option to help out.
Okay good.
I was concerned because anyone who uses gcc on solaris would find
themselves having to choose between a complete static link or
a dynamic link but with the additional headache of having to
distribute libgcc.so with their binary.
If we provide --static-libgcc and perhaps even make it the default
when linking executables on systems like solaris then one can continue
to dynamically link with libc and not worry if the end user customer
has libgcc.so installed.
Believe me this is a problem we don't want.
--Kaveh
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Qwest Internet Solutions