This is the mail archive of the 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]

rfc: limited shared libgcc widgetry

The following is good enough to build a shared libgcc on
Linux (i386, alpha, ia64), Solaris 2.5, and Irix 6.3 (nearly).

A couple of points:

  * libtool is not used because it does not (as far as I can tell)
    handle symbol version scripts, which we want for glibc
    compatibility.  Plus, I couldn't make libtool do what I want
    with a single tree cross compile; perhaps someone else could,
    but it seems awfully invasive.

    But even fixing all that, I deny that we could select the
    correct version script without target-specific hackery.  And
    once we've started on target macros, it's not so hard to just
    Do What I Mean directly.

  * The library is called, because I don't want it
    used accidentally.  I once discussed a scheme in which
    collect2 determined whether or not we really wanted to link
    against the shared library; I plan on persuing this, and
    IIRC, not all systems use different extensions for shared
    and static libraries.

  * The library is currently not used at all, since I havn't
    done the work on collect that I intend.  As such, we only
    verify that the library is buildable -- not nothing I suppose.

  * I am completely glossing over the issue of if, how, and where
    to install the shared library.

  * Need to come up with a better scheme for describing symbol
    exports.  Unlike gnu ld, solaris ld does not like symbol
    version scripts mentioning symbols that do not exist.  Irix
    (and probably others) has a simpler whitespace-delimited
    include/exclude scheme, but would at least hide certain parts
    of the implementation that we never intended to reveal.

  * Irix fails to build an n64 version of crtbegin/crtend, and
    so fails to link the n64 properly.  Unless I am
    mistaken, we probably fail to build any n64 binaries proerly.
    Can anyone confirm or deny?

  * I would appreciate a c++ someone going over the list of
    exported symbols to see that I havn't included anything 
    that shouldn't be in the external interface.  The current
    list is basicly everything except __terminate_func and
    __new_handler, both of which have public accessor functions.

  * We should decide what to do with some of the ancient, probably
    unused symbols in libgcc.  This includes the -a support, which
    I would be delighted to nuke from orbit.

  * Assuming this is not entirely the wrong way of doing things,
    I'll want other port maintainers (particulaly bsd, aix, hpux)
    to submit the required lines for their systems.

Not committed.



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