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 12:42:26AM -0300, Alexandre Oliva wrote:
> ... it collects the object file names, flags and libraries passed by
> GCC to the linker when doing a -shared link at libtool configure time ...

And what if this list changes depending on the gcc options?  

> Now, why it fails to find -lgcc_s in the list of
> flags passed to the linker escapes me.

Because with recent binutils we have

	gcc -shared			# -lgcc
	gcc -shared -shared-libgcc	# -lgcc_s
	g++ -shared			# -lstdc++ -lgcc_s

When linking libstdc++ itself, of course, we can't use the last,
so we have to link with gcc.  But we do in fact need the shared
libgcc, so we want to add -shared-libgcc.

Similarly with libjava, where we can't use the gcj driver that
defaults to the shared libgcc.

> Sure.  Which platform are we talking about, for a start?

Any and all linux with binutils 2.12.

> As in dropping static libraries from the dependency list when they
> happen to contain PDC that can't be added to shared libraries?  This
> would be great!

What in the world has this got to do with anything?  If you can't
add the code to the shared library, you didn't build the shared
library, did you?  Confusing the issue by trying to "work around"
this in some way is ... dishonest.

> How about starting with Solaris?  g++ -shared will fail if you build
> and install GCC without a shared libstdc++.  You have to use
> -mimpure-text to get the link to succeed.  This was actually the main
> reason that motivated the complicated hack above.

Well, gee, colour me unmotivated.  Either build the .a with -fPIC,
or build the .so, or accept ld's bitching.  It's certainly not a
good reason to present a fake view of what's actually happening on
the system.

ESPECIALLY since it's almost certainly a user error in the first place.

That's what's GOOD about having -zimpure-text: it's a "yes I really
meant to link non-pic code" sanity check.  I think it's a mistake that
gld doesn't at least warn about this by default.  Instead we'll get it
on non-x86 platforms like alpha and ia64 where the link will fail with
"gp-relocation against dynamic symbol" errors.


r~


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