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]
Other format: [Raw text]

Re: libstdc++ libtool lossage


On Thu, Feb 21, 2002 at 05:30:51PM -0300, Alexandre Oliva wrote:
> On Feb 21, 2002, Richard Henderson <rth@redhat.com> wrote:
> 
> > 	gcc -shared			# -lgcc
> > 	gcc -shared -shared-libgcc	# -lgcc_s
> > 	g++ -shared			# -lstdc++ -lgcc_s
> 
> There's something I dislike very much about this design.
> 
> Earlier, it was perfectly ok to use gcc to link multi-language
> applications and shared libraries, as long as the appropriate
> language-specific libraries were explicitly linked in.

True.  The ideal solution is to examine all of the object files
to be included in the link and see if any exception handling 
routines are needed, and make the decision based on that.  I
couldn't figure out how to fit that into the gcc driver.

Right now, what'll happen is that if EH routines are needed,
but shared libgcc not used, they'll be seen as undefined symbols.
If you use -Wl,-z,defs then you get the proper error about this,
but unfortunately not otherwise.

> Since linking with -lgcc instead of -lgcc_s is an optimization (I
> suppose), wouldn't it be reasonable to use the safe construct by
> default (-lgcc_s), and the static libgcc only if explicitly requested
> so?

Given the number of C-only shared libraries on the typical linux
system, this is a relatively important optimization.

> ... but it appears to me that it would help all packages that
> build C++ shared libraries out there, especially those that use
> libtool.

And why wouldn't they be using g++ to link instead of gcc?
AFAICS, libstdc++ and libjava are special cases here.


r~


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