Re: per-port symbol exports (was Re: libstdc++ related boostrap failure)

[Phil Edwards <phil at jaj dot com>]

On Fri, Feb 14, 2003 at 04:40:43PM -0600, Benjamin Kosnik wrote:
> 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....

This turns out to be a trivial fix to ld; patch pending.


> 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.

All true, and I don't plan on checking anything in until a port actually
needs it.  Symbols for 32-bit-only and 64-bit-only platforms don't bother
me in the least; that's a common situation.  If a specific port, or port
family, needs certain symbols, then I would want a more general solution.


> 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'm hoping this is the case.


> It's really, really important to not export the thread data if at all possible.

Yeah, exporting _Atomic_add_mutex bothers me.


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002