| |||||||||||
LSB 2.0 and C++LSB 2.0 and C++Posted Aug 5, 2004 4:45 UTC (Thu) by rfunk (subscriber, #4054)Parent article: LSB 2.0 and C++ JoeBuck mentioned this, but I think it needs to be emphasized... The article says: The LSB is explicitly mandated to focus on existing, deployed technology.... and: Opponents argue that the version of the v5 ABI documented in the LSB has never been distributed either - though, in all fairness, the required changes appear to be small."In all fairness"? Does the explicit mandate of specifying "existing, deployed technology" matter or doesn't it? If it doesn't matter, then it can't be used as an argument against the v6 ABI. If it does matter, then that should immediately invalidate the current draft until the required gcc changes actually get out into the world. Looks to me like the only rational thing to do is hold off on putting C++ into LSB until g++ stabilizes on a single stable ABI and that propagates out into the world. You can't standardize on a given ABI when it doesn't even exist yet.
(Log in to post comments)
LSB 2.0 and C++ Posted Aug 5, 2004 5:20 UTC (Thu) by rriggs (subscriber, #11598) [Link] Looks to me like the only rational thing to do is hold off on putting C++ into LSBI'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. 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. In this case, I think it is in Red Hat's interest to fight the inclusion of C++ in the LSB. 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. As market leader, that's what the ISVs will target. As a commercial software consumer, I just want a standard. I'd personally like it to be based on the v6 ABI, because of compatibility with the Intel compiler. But at this point, any standard the Linux distributors can agree on would be good.
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.
LSB 2.0 and C++ Posted Aug 5, 2004 19:27 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] The electronic design automation industry (and therefore all the chip design houses that rely on EDA software) have already standardized on RHEL. RHEL 4.0 has not shipped yet, though, so it would be good if it as well as its competitors could be LSB-compatible without kludges. It will be gcc 3.4-based, as will the distros coming from anyone else who releases a distro in that time period.
C++ ABI aMAJORissue?How,in a libreware standard community? 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.
|
|||||||||||