This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: GCC 3.0 Release Criteria


 > 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]