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: Understanding gnu.ver and symbol exporting.


On Tue, Oct 7, 2008 at 8:30 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> Hi Chris,
>> Adding this to gnu.ver, I get 4 abi failures, the last 3 future_error
>> symbols and the allocator_arg. So I'm missing something, and I'm
>> pretty sure it has to do with that extern "C++" block at the top of
>> the file. First, there's no std::f* section so do I have to do
>> something like:
>>
>> std::f[a-t]*;
>> #std::future_error
>> std::future[^_]*;
>> std::f[v-z]*;
>>
> hard to help for your specific problem in such a way, in the abstract...
>
> Anyway, in general, I can tell you something for sure: that "C++" block
> belongs to GLIBCXX_3.4, thus during the normal development work you are
> **never** adding exports to it. Only, from time to time, you have to
> tweak it in order to *avoid* the existing patterns to match
> inadvertently the names of new symbols, which of course are exported as
> GLIBCXX_3.4.11. I hope that helps...
>
> Paolo.
>

Ah, I see. So for example when <thread> was added, GLIBCXX_3.4 had to
be modified to exclude matching against std::thr* using something
like:
std::th[j-q]*;
std::th[s-z]*;

So is it correct to say that since there's no patterns for std::f*,
there can't be clashes between 3.4 and 3.4.11 for any symbol beginning
with f? But for allocator_arg, std::a[e-z]* matches, so tweaking would
be necessary?

Chris


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