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
- From: Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Date: Tue, 02 Mar 2010 01:03:30 +0100
- Subject: Re: PATCH: Support Sun symbol versioning in libstdc++-v3
- References: <yddocjek7pg.fsf@CeBiTec.Uni-Bielefeld.DE> <mcrljei7dxy.fsf@dhcp-172-17-9-151.mtv.corp.google.com>
Ian Lance Taylor <iant@google.com> writes:
> Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:
>
>> So here's the experiment:
>
> ...
>
>> # But still runs the default version of func.
>> $ ./func10-gcc
>> FUNC_2.0
>
> When I run your experiment on GNU/Linux, it prints FUNC_1.0 here.
As expected: at least I've understood how this is supposed to work there :-)
> So I assume that you are demonstrating that GNU/Linux style versioning
> does not work when using the Solaris dynamic linker. This is a pity
> but is not terribly surprising.
Right: my point being that it's useless to include the renamed symbols
on Solaris 2 even when exclusively using a GNU toolchain since they
don't work at runtime. If we always exclude them if they are no use at
runtime, and fix an issue where GNU ld does't follow the Solaris 2 ABI,
PATCH: Properly support Solaris 2 ABI for symbol versioning in GNU ld
http://sourceware.org/ml/binutils/2010-02/msg00457.html
the versioning info for libstdc++.so is identical between GNU ld and Sun ld.
If we can reach agreement that this is sensible, I'll post an updated
patch with additional fixes for the problems brought up here and stuff I
found myself.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University