Weekly Edition
Return to the Front pageRecent Features
| |||||||||||||
LSB 2.0 and C++
The Linux Standard Base is a
standardization effort aimed at making Linux friendly for application
vendors. By nailing down issues like which libraries should be available,
how packages are to be managed, where files should reside, etc., the LSB
seeks to create a standard environment which will be present on every
compliant distribution. Application vendors can then build their offerings
for that environment and, with luck, have them run everywhere.
A major release of the LSB (version 2.0) is in the final stages. The most recent plan had been to release this version at LinuxWorld, but, for reasons we are about to get into, that release may be delayed a bit. Version 2.0 adds a number of things; included therein is a description of the environment which should be available for C++ applications. A great many commercial programs are written in C++, so, for many vendors, the LSB is of little use until it covers that language. So the C++ description is a high-priority part of the LSB 2.0 release. The standardization of the C++ environment has run into some opposition, however, as seen by this posting to the gcc list and the subsequent discussion. Many people, including a number of gcc developers, are unhappy with the choices that have been made for the LSB 2.0, and are pushing for changes. The core of the problem is that the LSB specifies that compliant systems must offer a modified version of the "v5 ABI." This is the binary interface used by gcc 3.3; current versions of gcc 3.3, however, are not compliant with the specification. Patches exist toward a future 3.3.5 release which will bring it into compliance; this release will probably happen, though no promises to the effect have been made. The real problem, however, is that gcc 3.3 is already old technology, and is considered to be a dead end. Current development efforts are going into gcc 3.4 and even 3.5; gcc 3.4 can already be found on some systems (such as your editor's Fedora Rawhide box). gcc 3.4 is widely held to be a superior release; it has much improved performance, better interoperability with other C++ compilers, and better standards support. It also has a different and incompatible binary interface, of course. Since the C++ environment is only now being nailed down by the LSB, it is asked, why not go with the newer, v6 ABI, which will actually be relevant into the future? The reasons appear to come down to the following:
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. The stronger complaints seem to be that the LSB has made its choices based on the short-term needs of commercial Linux distributors, to the detriment of what the community wants. Of course, determining what the community wants can be problematic, especially since Richard Stallman has prohibited the gcc steering committee from cooperating with the LSB process. The truth of the matter is that the Linux Standard Base is in a bit of a bind. There is pressure from vendors to create a C++ standard in the near future, the LSB 2.0 process has already taken longer than expected, and, from the LSB's point of view, the v6 ABI has not yet reached a level of deployment or stability that would allow it to be used as the basis for a specification. The gcc C++ ABI remains a moving target, so any attempt to write a standard based on it is bound to encounter difficulties. The only option available at this time, assuming that the C++ section is not to be dropped altogether, is to go with the v5 ABI. We talked briefly with Stuart Anderson, the lead developer for the LSB written specification. His belief is that the LSB 2.0 release will go forward essentially unchanged, though perhaps with an added statement regarding the C++ ABI and the fact that it will change in the future. The v6 ABI will then be incorporated into the LSB 3.0 release, which is currently planned for about one year from now. It is possible, however, that the C++ section will be dropped from the version of the specification submitted to the ISO. Standards are a tricky subject in the free software world; they promote interoperability, but also freeze development in a community that values its ability to make changes and move forward. Occasionally a standard catches a development project at the wrong time; that appears to have happened with the C++ specification. As a result, some people are upset now. In a year or two, however, when the gcc C++ ABI has settled down and found its way into future LSB releases, few people will remember this episode. (Log in to post comments)
There is no "v5 ABI", and other LSB issues Posted Aug 5, 2004 3:23 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] You missed a key point. The version number for libstdc++ was not bumped between the 3.2.x and 3.3.x releases, because the original plan was to maintain strict ABI compatibility. Unfortunately this was not done correctly; 3.3 is not binary compatible with 3.2. Doubly unfortunately, RHEL 3.0's system compiler is gcc 3.2.3 (same with Fedora Core 1 and other distros that are still widely used). This makes it extremely difficult to support LSB 2.0 binaries on RHEL 3.0 without kludges. One need not side with Red Hat (I do not) to see that a standard that a major player can't live with is unlikely to be much of a standard.As you say, LSB 2.0 does not specify any existing release of GCC as the standard. The specification requires a bug fix, meaning that only an as yet unreleased version 3.3.5 would be compatible with the proposed standard. So it is incorrect to claim that the LSB project is standardizing on something that vendors are now shipping. Finally, RMS did not prohibit the steering committee from cooperating, when acting as private individuals. He prohibited the steering committee from taking an official position. It should not be surprising that he objects to something called the "Linux Standard Base" that mainly specifies the behavior of GNU software, and that has little to do with the Linux kernel (it's no more difficult to get a BSD system to comply with almost all of it). It's particularly problematic that the LSB seems to expect GCC, part of the GNU project, to ship a patch designed to their specifications (though since a 3.3.5 release was planned anyway and the requested patch is a bug fix, it will probably happen at some point). The LSB should change its name, and the new name should include neither "Linux" nor "GNU" (since it's equally possible to provide an environment that allows BSD or Solaris systems to run binaries that meet the specification).
A name change is in order Posted Aug 5, 2004 6:04 UTC (Thu) by uwaucs (guest, #6160) [Link] Particularly since Solaris 10 will support the LSB.
breakthrough on naming issue! Posted Aug 5, 2004 9:13 UTC (Thu) by bkoz (guest, #4027) [Link] Ok, most everything on this sad thread has been said and re-said in the gcc discussion. However, I've not noticed the obvious naming point yet, so I'll say it, because it has to be said.
If LSB kept the L, and just changed the "B" for base into "D" for disto, well then. That would be LSD! A much better standard already. I can't believe they missed that chance...
-benjamin
breakthrough on naming issue! Posted Aug 5, 2004 17:16 UTC (Thu) by tjc (subscriber, #137) [Link] If LSB kept the L, and just changed the "B" for base into "D" for disto, well then. That would be LSD! A much better standard already. I can't believe they missed that chance...This was discussed at length on Slashdot 4 or 5 years ago, back when Michael McLagan was promoting his own plan for Linux standardization.
breakthrough on naming issue! Posted Aug 6, 2004 1:06 UTC (Fri) by giraffedata (subscriber, #1954) [Link] I'm still waiting for the naming to go the other way: For "Linux" to start referring to a wider set of operating systems. A lot of people think it's vital to the definition of "Linux" as an operating system that the system contain the Linux Kernel. But I've always said that of all the things that characterize a "Linux" system, the kernel has relatively little influence.Already, I believe most sentences that apply to all the so-called Linux systems also apply to GNU/Hurd, FreeBSD, etc. And I remember a statement from Sun once claiming that Solaris was Sun's version of Linux. Why not? IBM did a similar thing with AIX. With IBM's help, I once outfitted a system with an AIX kernel that was hard to tell apart from Linux-kernel-based systems I use regularly. In many conversations, I referred to it as a Linux system; to do otherwise would be misleading.
breakthrough on naming issue! Posted Aug 6, 2004 1:23 UTC (Fri) by piman (subscriber, #8957) [Link] The word you're looking for exists. It's called "Unix" or maybe "POSIX-like" if you're really really pedantic.
Please let "Linux" mean the Linux kernel, otherwise we have no way to talk about it.
breakthrough on naming issue! Posted Aug 6, 2004 2:43 UTC (Fri) by giraffedata (subscriber, #1954) [Link] It's called "Unix" or maybe "POSIX-like"That's a different term, much more broad. It would include, for example, a standard AIX system, and that is quite distinguishable from Linux systems. Please let "Linux" mean the Linux kernel, otherwise we have no way to talk about it. I fought that battle valiantly when the name "Linux" was new. We have been beaten soundly. The vast majority of uses of the word "Linux" today are references to a class of operating system, not of kernel. But it's not that big a loss -- we definitely still have a way to talk about the Linux kernel -- just add that one word - "kernel." That's what I do now. And as for a word for operating systems that include the Linux kernel -- I still maintain there's no need for one.
breakthrough on naming issue! Posted Aug 7, 2004 22:51 UTC (Sat) by piman (subscriber, #8957) [Link] I seriously doubt your AIX system provided a Linux-like /proc, or sysfs/udev, or was bug-for-bug compatible with whatever thread implementation was being used at the time.
> The vast majority of uses of the word "Linux" today are references to a class of operating system, not of kernel.
I know absolutely no one that does that. Even the dumbest journalists know Solaris, Linux and BSD are different OSs.
breakthrough on naming issue! Posted Aug 7, 2004 23:50 UTC (Sat) by giraffedata (subscriber, #1954) [Link] I seriously doubt your AIX system provided a Linux-like /proc, or sysfs/udev, or was bug-for-bug compatible with whatever thread implementation was being used at the time. True, but my point is those are minor OS characteristics. I'm sure in some applications, they are critical, but they pale by comparison to all of what was the same. But more important: note that not all systems we call "Linux" share any of the things you mention (think of those that contain 2.4 kernels), yet we still use a single name for them. That's because they're minor differences on the whole. I know absolutely no one that does that. You're reading something extra, and absurd, into what I said, because when I said "Linux" is a class of OS, I certainly didn't say that Solaris and Linux are the same OS or even that Solaris is in that class called "Linux." Examples of OSes in the Linux class are Red Hat Linux, SUSE, and the myriad variations of those that their users create. Journalists hardly ever even write about kernels, so they wouldn't use "Linux" to mean the kernel. They use it to mean something like Red Hat Linux, which comprises the kernel, a bunch of GNU programs, X, OpenSsh, and so on. They compare "Linux" to Windows, which is by all accounts a whole operating system, not just a kernel.
breakthrough on naming issue! Posted Aug 8, 2004 2:54 UTC (Sun) by piman (subscriber, #8957) [Link] > True, but my point is those are minor OS characteristics.
So what's a 'major' OS characteristic? If you refer to the toolset, we have a separate name for that already, too... I see no gain by calling an AIX system with the GNU tools "Linux". It's a lie.
breakthrough on naming issue! Posted Aug 10, 2004 16:12 UTC (Tue) by giraffedata (subscriber, #1954) [Link] I don't think there are any indvidual major features. When the average person thinks of "Linux," he thinks of a vast array of features that, perhaps surprisingly, all the systems calling themselves Linux mostly have in common. Some major components that deliver these features are: the Linux kernel, Bash, GNU ls etc., sysvinit, X, KDE/Gnome, and lots and lots of other software. The kernel is less than 1% of Linux in many ways: lines and bytes of code, development effort, pages of documentation (description), questions asked about "Linux" in public mailing lists.So it's hard to see why we would define a class of OS based on the identity of that one component.
breakthrough on naming issue! Posted Aug 12, 2004 15:50 UTC (Thu) by AJWM (guest, #15888) [Link] I see no gain by calling an AIX system with the GNU tools "Linux".Agreed, but that's not what the original poster was saying. AIX-5L is certainly Linux-like, and it and several other Unix-derived systems will run Linux binaries (of appropriate CPU architecture). It's a lie. It is similarly a lie to brand all the FLOSS tools supplied with most Linux (and many other OS) distros as "GNU tools". Many (most?) are not part of the GNU project and many are not even distributed under the GNU license, but some other free/open license. Perhaps we do need yet another name. POSIX and UNIX both have rather rigid (and somewhat dated) requirements as to their use, you don't like "Linux" as a generic term (probably a good thing, it dilutes the trademark), and calling anything with a mish-mash of GNU, non-GNU project GPL'd, BSD, Apache, Artistic, CPL, etc, etc, licensed tools should hardly be called GNU/anything. "Freenix" has been used as a generic term to cover Linux, the BSDs, etc, but there can be vast "feel" differences between those. (Not necessarily from a user view if he's just using a graphic desktop, but certainly from an admin point of view.) Something that conveys the flavor of a modern, user-oriented unix -- "muonix", perhaps? (Pronounced "moonix", so as not to confuse it with some new electronics-like technology based on muons ;-)
RMS and LSB Posted Aug 5, 2004 9:15 UTC (Thu) by angdraug (subscriber, #7487) [Link] RMS did not prohibit the steering committee from cooperating, when acting as private individuals. He prohibited the steering committee from taking an official position. And I believe that RMS is perfectly right in prohibiting endorsement of LSB. Not only because of the name, there is a more substantial problem: LSB's primary purpose is to enable proprietary software, while position of RMS and FSF in general towards proprietary software is well known: it is negative. It would be against all principles of FSF to officially endorse proprietary software standard.
RMS and LSB Posted Aug 6, 2004 1:23 UTC (Fri) by KotH (subscriber, #4660) [Link] Well, standardization makes writing proprietary software much easier, but you have to also agree that it is a pain to write portable software, even if you just want to support all linux distributions. I actualy miss the times when a simple Makefile with a few constants at the top was enough to compile something. No mess with autoconf/automake/libtool. LSB is for me a step into the direction of enabling simple sofware to work again with simple Makefiles w/o the need to learn the autotools or to handcraft a configure script.
LSB and portable software Posted Aug 6, 2004 8:15 UTC (Fri) by angdraug (subscriber, #7487) [Link] it is a pain to write portable software True. But no amount of standardization will make all the ancient incompatible systems suddenly go away. If you want your application to be portable without fancy autotools scripts, your only option is (and will be) to use Ruby, Python, or another scripting language, and let the language developers deal with the portability thing. LSB is for me a step into the direction of enabling simple sofware to work again with simple Makefiles w/o the need to learn the autotools or to handcraft a configure script. Quoting "Introduction" to LSB 1.3: The Linux Standard Base (LSB) defines a system interface for compiled applications and a minimal environment for support of installation scripts (emphasys mine). You see, LSB is not about source code, it is about binary software.
RMS and LSB Posted Aug 6, 2004 3:25 UTC (Fri) by bkoz (guest, #4027) [Link]
I think RMS is completely correct on this.
It gives me pause when a group that charges $$$ for positions on its executive board, requires $$$ for certification etc. is establishing standards for free software. Hey, who spiked the water cooler, huh?
Personally, I encourage all linux hackers to work together, regardless of favorite distribution or employer.
"Nations will learn to work together only by actually working together."
The only way we are going to get true and meaningful compatibility between different distributions of linux is for the linux distributions to work on this problem directly, with full and equal rights and voting priviledges, not by some self-appointed external group.
RMS and LSB Posted Aug 6, 2004 5:28 UTC (Fri) by Xman (guest, #10620) [Link] Honestly, much as I hate to say it, committees work much better when you have to pay at least a nominal charge for a seat at the table. It ensures that everyone sitting at the table has at least some kind of a stake in the outcome. As for charging for certification, it's really hard to come up with a certification process that doesn't involve paying some kind of trusted third party to do testing. So then the question is only who pays for the testing, which inevitably leads to the testee.
I agree having $$$'s in the process makes it a pain, but frankly it works better than all the other solutions (beyond simply not having a standard and letting natural forces push a standard forward).
Design by committee Posted Aug 6, 2004 8:18 UTC (Fri) by angdraug (subscriber, #7487) [Link] I agree having $$$'s in the process makes it a pain, but frankly it works better than all the other solutions (beyond simply not having a standard and letting natural forces push a standard forward). There, you say it yourself: letting natural forces push a strandard is a better solution. Dao rules ;-)
LSB 2.0 and C++ Posted Aug 5, 2004 4:45 UTC (Thu) by rfunk (subscriber, #4054) [Link] 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.
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.
LSB 2.0 and C++ Posted Aug 5, 2004 6:55 UTC (Thu) by Xman (guest, #10620) [Link] I'm missing something here. Intel and the GCC folks have already worked out a standard for C++ compilers, and while they don't have 100% perfect compatibility, it's increadibly close.
It sounds like the problem is more with libstdc++, and there I have to say the logical choice is to go with the version included in gcc 3.4. There are simply dramatic improvements in the quality and efficiency of the libstdc++ code base.
Honestly, if they aren't going to go with 3.4's libstdc++, I think they should just forgo having C++ in the LSB standard altogether. Yeah, it's a pain, but that allows for LSB 2.1 to come out with C++ at some later date.
LSB 2.0 and C++ Posted Aug 5, 2004 7:30 UTC (Thu) by fandom (subscriber, #4028) [Link] In the commercial world it seems to be quite usual to use computerprograms running for years and years, for example, it is still quite common to have DOS programs running in Windows. Does the LSB deal with that kind of backward compatibility? and if it doesn't what is the point anyway?
mmm static linking Posted Aug 5, 2004 9:24 UTC (Thu) by stuart (subscriber, #623) [Link] Well if you statically link your program (which is what was done with a lot of the programs still running 20 years after they were last built) the problem does tend to go away.
Stu.
mmm static linking Posted Aug 5, 2004 11:09 UTC (Thu) by rjw (guest, #10415) [Link] Or even just run it with an old set of libraries, either via linker env vars or chroot / process private namespace tricks...
mmm static linking Posted Aug 5, 2004 14:30 UTC (Thu) by uwaucs (guest, #6160) [Link] No, glibc likes to dlopen things like libnss even when statically compiled, which then breaks on a more recent glibc. Try a running a binary statically compiled on a Debian potato system on unstable and you'll see what I mean.
mmm static linking Posted Aug 5, 2004 23:42 UTC (Thu) by AnswerGuy (guest, #1256) [Link] dlopen() is different than linking and is isolated and specific classes of library. So the PAM and NSS, the perl, Python, and Apache binary modules and things of that nature are affected. Obviously the PAM and NSS are the biggest issues here.
Clearly if you fully statically linked specific PAM and NSS modules into your application you'd no longer support the /etc/pam.d and /etc/nsswitch.conf interfaces --- you'd be locked into specific authentication modes and services.
That's not impossible for a highly vertical turn-key system; but it runs counter to the decade long trend in open systems management. It's more of a market and social problem than a pure technical one.
JimD
Binary compatibility necessary for ordinary computer users Posted Aug 6, 2004 12:13 UTC (Fri) by eru (subscriber, #2753) [Link] Long term binary compatibility is not useful only to closed software vendors, as many seem to think. If I have a well-working binary for a large free software program, why should I be forced to recompile it just because I upgrade the Linux distribution or switch to another? (even if I theoretically can, it can sometimes be a lot of work and perhaps require installing compilers and more disk space I currently do not happen to have).Good binary compatibility is something that often helps end-users concretely. Linux needs it in order to be more than an OS for hackers.
LSB 2.0 and C++ Posted Aug 5, 2004 10:43 UTC (Thu) by nathan (subscriber, #3559) [Link] To interoperate C++ programs one needs to define two things, the coreC++ ABI and the standard library ABI. The former has a vendor neutral standard, which g++ implements (with varying degrees of conformance), starting with gcc 3.0. You should think of the library as a system library of the same nature as libc. The library has no vendor neutral ABI standard, and is part of what LSB is attempting to standardize. Sometimes 'C++ ABI' is used to refer to the core language ABI (I do that), but in this discussion we're refering to the library's internals too.
g++ 3.4 deliberately changed the core and library ABIs. The core
ABI patches are not small. They can have far reaching consequences
I have no desire to spend effort maintaining 3.3, there are better
LSB 2.0 and C++ Posted Aug 6, 2004 12:02 UTC (Fri) by eru (subscriber, #2753) [Link] Going forward from 3.4 there is every intention of maintaining a stable ABI.I think I heard the same thing said about 3.0, 3.1, 3.2 ... I'm beginning to wonder if the goal is even practically attainable, given the nature and complexity of C++ and its library.
LSB 2.0 and C++ Posted Aug 8, 2004 0:43 UTC (Sun) by garloff (subscriber, #319) [Link] Reading the comments, it seems like some things have not been said:
LSB 2.0 and C++ Posted Aug 8, 2004 16:30 UTC (Sun) by rfunk (subscriber, #4054) [Link]
Once again, these two are contradictory. Either LSB specifies existing practice or it doesn't. If it does, then requiring everyone to patch their systems to be compliant is not an option.
|
|||||||||||||