This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: PATCH: Support Sun symbol versioning in libstdc++-v3
Jakub Jelinek <jakub@redhat.com> writes:
> On Wed, Feb 24, 2010 at 03:51:39PM +0100, Rainer Orth wrote:
>> * config/abi/pre/gnu.ver (GLIBCXX_3.4.5): Remove duplicates.
>> (GLIBCXX_3.4.6): Likewise.
>
> This is a serious ABI change. Those symbols were mistakenly exported
> in GLIBCXX_3.4 version, then fixed up to use a version in which they were
> actually introduced, but in the wild there are programs using both
> symbol versions for those symbols. .symver directive is used to alias
> the same internal symbol into both symbol versions (but in theory and e.g.
> glibc uses it heavily two different implementations of some routine, one
> exported say as foo@GLIBC_2.0 and another as foo@@GLIBC_2.6). This is
> something Sun symbol versioning scheme (which is much more limitated than
> the GNU symbol versioning scheme) doesn't handle, but you definitely can't
> break ABI compatibility on Linux and other targets because of it.
I didn't know about that, the duplication seemed completely pointless at
first sight. You should add a comment explaining what's going on there,
since this is highly unusual. I certainly never intended to break the
ABI on any platform, that would be seriously counterproductive and the
worst one could do. Sorry if I sounded otherwise.
As I said, the Sun ld engineers never saw a need for something like this
(out of sheer luck, they said, though I sort of claim it's more design
and review before changes escape into the wild :-), so it's not present.
> Your script to create Sun versioning script needs simply to cope with it
> somehow.
Ok, no problem here. Maybe I introduce some sort of #ifdef facility,
perhaps along the lines of what I did in the libgomp mapfile, to handle this.
Thanks.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University