LSB 2.0 and C++

Posted Aug 5, 2004 5:43 UTC (Thu) by rfunk (subscriber, #4054) [Link]

I'm sorry, but that's not very helpful either. Commercial software vendors need a standard to which they can deploy. There exist many commercial C++ libraries and applications with C++ APIs. Without a solid standard, it is very difficult to integrate more than one vendor's product.

Yes, but that's the same situation we've already been in. We've never had a standard C++ ABI, and everyone has limped along so far. Waiting to specify it won't make it worse.

If the LSB is released without a standardized C++ ABI, the de facto standard will become that which is in the current and future versions of RHEL.

I doubt it. Not enough people are willing to pay the price for RHEL for that to become the defacto standard.

As market leader, that's what the ISVs will target.

When you talk about market leader, you have to define the market. RHEL might be the market leader for a certain piece of the Linux market, but certainly not for the whole Linux market (which I thought LSB was targeting).

But at this point, any standard the Linux distributors can agree on would be good.

Yes, well, right now it looks like there isn't a single one they all can agree on yet. Some are on the gcc 3.2 flavor of "v5", while others are on the gcc 3.3 flavor of "v5", and the two are incompatible. Once gcc 3.4 spreads, it's more likely that the distributors will be able to agree on a standard -- v6. But that's not going to happen until next year.

Thus, it makes sense to wait until next year before defining this standard.

Posted Aug 5, 2004 17:27 UTC (Thu) by Duncan (guest, #6647) [Link]

> The company I work for is attempting to migrate
> applications from Solaris to Linux, and a major
> issue for us is the lack of standards for the C++ ABI.

Why is that such a /major/ issue? The middle letter of ABI of course
stands for binary, it's the /binary/ interface. How can that be a /major/
problem in a community defined by its open source (libre) nature? Ship the
source, and let the distribution or individual users compile it as
necessary, after running an appropriate configure script that detects all
the necessary stuff. Issue solved. (Granted, certain standardization
makes those configure scripts far less complex, but that's a /minor/
issue, not the /major/ one you're making yours out to be.)

Proprietary and can't do that? Anyone in that situation is by definition
creating their own problem by ignoring Linux community openness standards,
no matter /what/ other sort of "standards" label they may slap on their
product. IMO, they deserves any problems they have as a result, and no
special effort on the part of the community, IMO, need be made to ease
them.

As for the LSB, the first letter stands for Linux. One of the Linux
traditions is that "it'll be ready when it's ready." Yes, it'll hurt to
either drop the C++ part and hit the ISO date, or drop the ISO app and
start over, but in this case, "it's not ready." Thus, if the ISO process
must be restarted, or a compromise reached whereby the C++ definition
isn't included in the ISO version, so be it. That's the Linux way. By the
time the process is ready for ISO submission again, the C++ stuff should
be ready for it. Otherwise, take the Linux out and call it the PLSB
(POSIX-Like), or make it the IPSB (Intel Posix) and straight up require
the Intel compilers for all I care. It really doesn't deserve the Linux
moniker anyway if it primarily benefits proprietaryware folks, which is
what a /binary/ interface standard by definition does.

Duncan, now running an ATI Radeon 9200 with the open drivers, because the
dual video out doesn't work on the open NVidia drivers, because NVidia
refuses to provide specs, and I had enough of tainted kernels and
proprietaryware.