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

[Phil Edwards <phil at jaj dot com>]

On Fri, Feb 14, 2003 at 12:17:30PM -0500, Phil Edwards wrote:
> On Thu, Feb 13, 2003 at 09:17:04PM -0600, Loren James Rittle wrote:
> 
> > I think I shall allow Phil to handle considering the export of ABI
> > symbols that are conditionally available on a per-port basis.
> 
> This will either be trivial or fugly, depending on GNU ld.  I'll tackle
> this today.

Welcome to camp fugly.

Ideally, we'd like to just copy over the main version script and then cat(1)
on some text, resulting in:

    GLIBCPP_3.4 {
        ...
    };

    ...
    # end of linker-map.gnu

    # This text is appended specifically for wonky64-unknown-gurgle9.7:
    GLIBCPP_3.4 {
        ...
    };

This is specifically disallowed in ld, even if the symbols themselves
don't clash.  Bummer.


Second attempt:  inside the version block, allow a hook for arbitrary text,
e.g., the main file looks like

    GLIBCPP_3.4 {
        # Don't edit this line.  It's special.

        ... everything that's currently there ...
        one;
        two;
        three     # note the lack of semicolon
    };

and most ports would leave it like that.  Some ports could specify an
extra file to be dropped in with the magic of sed:

    GLIBCPP_3.4 {
        # Don't edit this line.  It's special.
        # This text is inserted specifically for wonky64-unknown-gurgle9.7:
        foo;
        bar;
        baz;

        ... everything that's currently there ...
        one;
        two;
        three     # note the lack of semicolon
    };

We have to do that at the beginning (well, anywhere but the end), because
of the last-entry-gets-no-semicolon grammar, and we can't rely on the port
text contents.

However, to make this not suck for port maintainers, we'd like for the
arbitrary text to be able to use both the normal mangled symbols, and the
'extern "C++"' blocks, arbitrarily.  E.g., instead of "bar" above,

    GLIBCPP_3.4 {
        # Don't edit this line.  It's special.
        # This text is inserted specifically for wonky64-unknown-gurgle9.7:
        foo;
 *      extern "C++"
        {
            quux;
            quuux;
            quuuux     # no semi here either
        };
        baz;

        ... everything that's currently there ...
 *      ... including our own big "C++" block ...
        one;
        two;
        three     # note the lack of semicolon
    };

Sigh.  GNU ld only permits /one/ extern block, and it must be the /first/
thing in the list, i.e., where "foo" is in my running example.  This is
not documented, and appears to be a bug in the grammar.

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.


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