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?
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?
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!
What is also disturbing, is the handling of libgcc_s.so,
which you on the one hand need to ship with program, but which partly
breaks binary compatibility on the other hand.
Yes, libgcc_s.so is a bit of a mystery. Newer versions can
always run programs built against older versions, though,
so as long as you build your app with the least common denominator
version of the compiler, you should be safe.
Anyway, things are
improving and I am pretty sure they will be sorted out in the (near?)
future.
Yes, there is hope on the horizon.
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.)
Cheers,
Dan
--
Trying to get a job as a c++ developer? See
http://kegel.com/academy/getting-hired.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
