This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: per-port symbol exports (was Re: libstdc++ related boostrapfailure)
On Fri, 14 Feb 2003 16:33:07 -0500
Phil Edwards <phil@jaj.com> wrote:
>I'm testing a fix now, but this will put us in the same situation we were
>in when we first wanted to do demangled names: it's a rarely-used gld
>feature with a bug, we're fixing the bug, but can we require a minimum
>version of ld? We did previously, I feel we should be able to for 3.4.
Of course. I think imposing a requirement on ld is fine as long as
autoconf takes care of it.
I think you can pretty much count on not hacking a solution that
includes an extern C++ bit. I don't think requiring per-port mangled
names is unreasonable. You have, however, exceeded my expectations on
this front before....
More to the point, however: why? The current script has "extra" symbols
that are only present on 64 bit systems, and symbols that are only on 32
bit systems that don't apply to 64 bit systems. Having symbols that
don't exist on a particular port in the general link map isn't a
problem: they are only exported if found.
Is the problem that BSD has different linkage for this symbol than
linux? I thought this symbol only existed on generic configs. If this is
the case, can somebody figure out why? I would hate to invent (or
rather, Phil invent) a whole new machinery if it's just some latent bug
uncovered in the last check-in.
I can be convinced that this is useful, but I'm pretty wary. The symbol
versioning bits are already confusing enough with everything in one
place. Adding a configuration step, and exploding the options, should be
avoided if at all possible.
It's really, really important to not export the thread data if at all possible.
-benjamin