>
> It is certainly a problem of similar scope, although not exposing
> stuff like the STL probably also means not using it internally, since
> it's kind of tricky to require the linking in of multiple STL
> implementations if we use one and the app using our libraries uses
> another.
No, no it isn't. This is why they inventing symbol versioning.
> Not saying it's impossible, just hard.
It depends on your solution.
If you wanted absolute full binary compatibility in absolutely all
cases, you'd just include STLPort as a dependency and be done with it,
since your real issue is libstdc++ not the C++ ABI.
This is not hard at all. Since the C++ ABI of gcc hasn't changed
since 4.0 (or maybe there was one super-corner case that was fixed in
4.1, but that could easily be fixed using -fabi-version to select an
abi version), this would buy you compatibility.
We would not be the first people to try to maintain compatibility of a
library over multiple versions of G++.
We won't be the last.
It's certainly not something that would make me throw up my hands and
move to lua.
;)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 27 01:58:23 2006