[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