Dan,
Dan Kegel wrote:
Kay Ramme - Sun Germany - Hamburg wrote:
The core is already 'C' based. Please see my other posting.
Your other post made it clear that the core is C++
internally, but exports only pure C functions to the world. Right?
You are right.
That's not quite 'C' based, because of the symbol versioning
problems you're well aware of, so you need to make a stronger
statement here (like
"It's C++ based, but all global symbols
it exports or imports (even the internal ones used by the C++
compiler and libstdc++) are pure C,
and we absolutely, positively promise that you can use this
C interface to link to your C++ app, no matter what version of
C++ you used to compile your app in").
Can you make such a promise?
Certainly not, as this is a compiler/ABI issue.
The C++ ABI on Linux is a moving target;
What is disturbing here is, that it even (as you said) breaks in
minors, AFAIK even without notice, and sometimes it seems even without
intention.
I've been watching, and as far as I can tell, the ABI changes
are always intentional and announced. Doesn't mean they're
not annoying, though!
Having had a versioned C++ ABI, would have been helpful.
The C ABI on Linux, on the other hand, remains relatively rock-solid.
Any low-level library that wants to have a hope of being
universally usable should strongly consider being based
solely on C and not on C++.
Actually, a C-library differs to C++-library only in terms of ABI and
does not need to differ in terms of implementation language. In other
words, it should be perfectly valid, to implement a library providing
a C interface in C++. The implementation language should really be an
implementation detail.
Should be, but might not be, or at least, it might take a lot of skill
to make it so.
You pointed out as much in your previous message:
> Unfortunately it is not necessarily true,
> that libraries compiled with different (in terms of ABI)
> C++ compilers can be used in the same process, because of symbol
conflicts.
Although maybe having URE link against libstdc++.a would
remove this part of the problem.
(http://gcc.gnu.org/PR21405 talks about this issue a bit with
regards to STL inlines.)
As there is AFAIK not formal way, to see that the g++ ABI changed
incompatible, there is IMHO not real value in solving that. As anybody
might just link against an incompatible C++ library anyway. Or do you
see some solutions here?
What I originally wanted to say is, that we _really_ can solve the core
UNO ABI issue in a compatible manner, if needed. Either by linking
statically or changing the implementation ;-).
Cheers,
Dan
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
