This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [libstdc++] Port-specific symbol exports, porting notes


> > For 2.11, we've never created symbol versions.
> >
> > For 2.11+backport, we will not create symbol versions starting with 3.4.
> 
> Ok, this is fine with me with the proper warning message.
[...]
> > Absolutely.  I've got an AC_ warning in there now, but am postponing
> > testing until the autocrasher finishes its afternoon thrashing.  Also,
> > this needs to be added to the install information.


I've added some warning messages to the configure tests, but haven't yet
checked them in.  If GNU ld 2.14 is used, they already get

    checking versioning on shared library symbols... gnu

Let's explore the non-bleeding-edge possibilities.

Here's what now happens if the user asks for symbol versioning, but isn't
meeting some general prereqs:

configure: warning: === You have requested some kind of symbol versioning, but
configure: warning: === either you are not using a supported linker, or you are
configure: warning: === not building a shared libgcc_s (which is required).
configure: warning: === Symbol versioning will be disabled.
checking versioning on shared library symbols... no


Here's what happens if GNU ld 2.11 (with or without backport) is used:

configure: warning: === Linker version 21100 is too old for
configure: warning: === full symbol versioning support in this release of GCC.
configure: warning: === You would need to upgrade your binutils to version
configure: warning: === 21400 or later and rebuild GCC.
configure: warning: === Symbol versioning will be disabled.
checking versioning on shared library symbols... no


Here's what happens if GNU ld 2.12 or 2.13 (i.e., what 3.3 currently
supports) is used:

configure: warning: === Linker version 21390 is too old for
configure: warning: === full symbol versioning support in this release of GCC.
configure: warning: === You would need to upgrade your binutils to version
configure: warning: === 21400 or later and rebuild GCC.
configure: warning: === Symbol versioning will be disabled.
checking versioning on shared library symbols... no

So, same thing.

The v3 versioning framework is set up so that other kinds of linker
versioning scripts, e.g., Sun's linker which introduced the idea, can be
dropped into place.  We call them styles.  Only one kind of style has
ever been contributed, GNU ld.  Possibly a solution to this is to add
another style for the 2.13 case, "gnuold", which is the same as "gnu"
but with the broken block support.  In such a case, here's what could happen:

configure: warning: === Linker version 21390 is too old for
configure: warning: === full symbol versioning support in this release of GCC.
configure: warning: === You would need to upgrade your binutils to version
configure: warning: === 21400 or later and rebuild GCC.
configure: warning: === Almost there!  Almost there!  Maybe we can fake it.
checking versioning on shared library symbols... gnuold


Maintaining two copies of the almost-same file would be a PITA.
Somebody wise in the ways of perl could probably automate the production
of linker-map.gnuold from linker-map.gnu, but that person is not me.

Also, note that if anybody wants to actually /use/ the per-port symbol
exporting functionality, they /have/ to use 2.14 for the parser fix.

Thoughts?  Other ideas?


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams


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