On Fri, 10 Jan 2003, Dan Kegel wrote: [...]
I don't know the particulars, but I do know that g++'s ABI only very recently stabilized.
^^^^^^^^^^^^^^^^^^^^^^^^ Isn't that a contradiction in terms?
[...]
(There was one little ABI tweak between 3.2 and 3.3, and there may be more later, but they probably won't break many apps.)
That too seems incompatible with something declared 'stable'.
Not that I have anything against C++, I like OO programming. But these g++ compatibility issues have been like a cold shower.
<rant class="my opinion only">
From the point of vue of an ISV, distributing a Wine binary is already
enough trouble with the C library changing their internal implementation (which of course they are absolutely free to do since it's *internal*) and FreeType breaking backwards compatibility in minor releases, but if ISVs also have to deal with g++ changing their ABI on a regular basis... Well, I guess ISVs could always compile these libraries with Visual C++ and ship them as Windows dlls and thus benefit from a stable and Wine compatible ABI... </rant>
On January 10, 2003 02:07 pm, Francois Gouget wrote:
and FreeType breaking backwards compatibility in minor releases, but if ISVs also have to deal with g++ changing their ABI on a regular basis...
A valid concern. But it should be a configure option (--with[out]-khtml), so they can easily disable if need be. Anyway, people should not need to ship an embedded Wine. With a bit of luck, we will ship a 0.9 this year, (and hopefully 1.0), it should be like glibc soon :). Besides, the interface to _Wine_ is always C, it doesn't matter that Wine uses C++ internally. If there are compatibility concerns, we just statically link -lstd++, and be done with it.
Francois Gouget wrote:
On Fri, 10 Jan 2003, Dan Kegel wrote:
(There was one little ABI tweak between 3.2 and 3.3, and there may be more later, but they probably won't break many apps.)
That too seems incompatible with something declared 'stable'.
Not that I have anything against C++, I like OO programming. But these g++ compatibility issues have been like a cold shower.
Yes, indeed. But things are looking *much* better. As I mentioned in my links, there's now an ABI standard that all c++ compilers can conform to, and at least Intel, SGI, and Gnu are all trying very hard to conform to it. gcc 3.0 was the first gcc to try to conform; gcc 3.2 fixed a bunch of conformance problems; gcc 3.3 fixed a couple tiny ones that became evident after 3.2 was released.
<rant class="my opinion only"> >From the point of vue of an ISV, distributing a Wine binary is already enough trouble with the C library changing their internal implementation (which of course they are absolutely free to do since it's *internal*) and FreeType breaking backwards compatibility in minor releases, but if ISVs also have to deal with g++ changing their ABI on a regular basis... Well, I guess ISVs could always compile these libraries with Visual C++ and ship them as Windows dlls and thus benefit from a stable and Wine compatible ABI... </rant>
The g++ ABI will *not* change on a regular basis. It is rapidly converging on the portable C++ ABI shared by several vendors, and defined in a standards document.
- Dan
On Fri, 10 Jan 2003, Dan Kegel wrote: [...]
The g++ ABI will *not* change on a regular basis. It is rapidly converging on the portable C++ ABI shared by several vendors, and defined in a standards document.
That's good news. especially if multiple vendors use the same ABI it seems all the more likely to actually be stable.
Francois Gouget wrote:
On Fri, 10 Jan 2003, Dan Kegel wrote:
The g++ ABI will *not* change on a regular basis. It is rapidly converging on the portable C++ ABI shared by several vendors, and defined in a standards document.
That's good news. especially if multiple vendors use the same ABI it seems all the more likely to actually be stable.
Yes. Too bad Microsoft isn't one of those vendors :-)
-
Dan Kegel -
Dimitrie O. Paun -
Francois Gouget