[v3] <regex> implementation foundation, version 1

Paolo Carlini pcarlini@gmail.com
Sun Jun 20 04:28:00 GMT 2010


Hi,

> The offending container is in fact a std::stack of indexes into a
> std::vector of a type defined private to the library.  It doesn't
> matter:  the genesis of the problem is that the linker script places  
> all
> symbols matching std::v* (or std::d*) in version GLIBCXX_3.4.  These
> symbols were not in that older version, so boom there's an ABI
> incompatibility.  It does not matter what type the vector is
> instantiated on, it will fail the ABI check.

As I said in a previous message - did you get it in your mailbox? -  
this is a quite common problem, just tighten the existing old pattern  
in the linker script to *not* match the new symbols you want to export  
now, then add a new pattern at the last open version for the new  
symbols. If you look back in subversion, I did something similar very  
recently too, when I changed basic_string the last time. No biggie.  
But...

> I will continue to see if I can just tweak things to hide the symbols
> (suggestions are welcome).  It's not a show stopper:  I can back out  
> the
> additions to the library and just keep everything in headers if worse
> comes to worst.

... I would suggest to do that first, at least as an initial  
approximation. When you will be *really* sure that your data  
structures are stable, then you will finally identify some large out  
of line functions that you want to explictly instantiate and export,  
maybe involving vector too. I would not attempt to do that now, it's  
way too early. And in any case if it's all about templates, doesn't  
seem to me at all urgent for code size, only maybe for compile time  
performance, because weak linkage helps you anyway for large  
functions. Just as an example, vectors are used also in <random> and  
we don't have any urgent plan to export anything.

Paolo 



More information about the Libstdc++ mailing list