Re: [gtkmm] cannot make gtkmm-2.2.12 (with MinGW for MSVC)

[nick <nick anvil com>]

On Fri, 2004-09-24 at 11:23, Paul Davis wrote:
> >It's a tad off topic for the list but I might as well repeat it.
> 
> except that its not correct ...
> 

> there is no C++ ABI. none has ever been specified by any standards
> body, and Stroustroup is on record as opposing standardization of
> things like name mangling precisely because it can act as the "canary
> in a coalmine" of problems caused by mix-n-match use of compile tool
> chains.
> 

By standards body I assume you ISO/ANSI and maybe ECMA? You can't lock
down a binary interface when the language keeps changing so much.

If you've been following the libstdc++ list discussion on the LSB
attempts to fix things you see it's a real can of worms. C++ just keeps
changing to fast. 

There are plenty of C++ ABIs defined on a per platform basis. Sun has
their own, HP have one, Intel have one. It only make sense to define an
ABI on a per processor/platform basis. There's not much ISO can do about
it apart from keeping the language stable and making extensions
backwards compatible.

Maybe if name mangling had been standardised things would be a bit
easier now. Debugging C++ code is a pain because of things like that.
It's not like ABI compatibility can never be achieved and it's a goal
worth pursuing. The fact that gcc 3.x isn't even ABI compatible with
different versions of itself shows how hard this is. 3.x was supposed to
be the release that nailed this down.

> >The C ABI has been standard for a long time now so you can mix and match
> >as you wish. Thus gtk+ is easier to use from a compilation point of view
> >than gtkmm. 
> 
> there is no C ABI either. a few companies (e.g. Intel) have tried to
> define one for particular platforms, but that's about it.

There is a C ABI for almost all processors you care to mention. There's
no unique one true standard. That's why I can build and link to
precompiled libraries mixing compilers quite happily. I've been doing so
for years. There are the occasional problems but C is a much simpler
language ABI wise than C++. 
As a rule don't mix compilers but the fact is you often can and people
make use of this fact all the time especially when cross compiling.

> __stdcall. Windows has at least two different C ABI's, although I
> think that gcc for windows has been hacked to allow it to generate
> either one. Not sure about that, however.
> 
True, it's ugly out there. These things are by no means simple but we're
arguing the same thing here. Don't mix compilers and linkers. The fact
that gtkmm can be built using several different methods on Windows makes
this all the more complicated.

Cheers

Nick