Weird issue with .clone symbol

Paolo Carlini paolo.carlini@oracle.com
Thu Oct 15 02:38:00 GMT 2009


Hi,
> Jan Hubicka wrote:
>   
>> Well, all clones should be static so they probably should not appear in
>> libstdc++ compatibility suite.  I will try to figure out what is going
>> on here.
>>   
>>     
> Humm, I think you misunderstood, the clone itself is in the object code
> of the user, it wants a symbol which currently is not exported, not
> viceversa. In other terms, in order to solve this issue the trivial way
> I would export additionally from the .so:
>
> _ZNSbIwSt11char_traitsIwESaIwEE12_S_constructIPKwEEPwT_S7_RKS1_St20forward_iterator_tag
>   
thus, I'm committing the below.

In my understanding all the _S_construct<> instantiations must be
exported from the .so, even if they are used only by the string
constructors: in general, if the user wants debug-mode, no implicit
instantiations are suppressed for string (because no extern templates
are used) and when the user also passes -fno-implicit-templates, the
constructors end up lacking the required _S_constructor<> helpers,
because neither implicitly instantiated in the .o neither exported by
the .so.

Tested x86_64-linux.

Paolo.

//////////////////
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CL_exports
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20091015/96971ee1/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch_exports
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20091015/96971ee1/attachment-0001.ksh>


More information about the Libstdc++ mailing list