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

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 libgcc_s.so, 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 libgcc_s.so 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.



r~

d-libgcc-1.gz


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