On 08/06/2011, at 4:27 AM, Alexander Neundorf wrote: > On Tuesday, June 07, 2011 08:58:22 AM Thiago Macieira wrote: > ... >> LSB has lost track of what's recent. Just take a mildly old / relatively > > I don't know whether I misunderstood the idea behind LSB, but even RHEL and > SLES (forgot the exact versions, they were relatively old), which claimed > they > would comply to the same LSB version, were not binary compatible. The STL > differed, some function from std::string was inlined on the one system and > called some internal STL function, which did not exist on the other system. > Should that have worked ?
I'm not familiar with the specifics of the particular case you mention, but there are at least a few possibilities: (1) The application using std::string might not have been getting built with LSB compilers - if you build with the standard g++ compiler, then you are not talking about LSB anymore. Building with lsbc++ instead puts g++ into "LSB mode" which should prevent the use of non-LSB symbols/libraries if things are all working correctly. (2) The RHEL/SLES versions might not have actually been LSB-compliant. The LSB does have a battery of tests that a distribution needs to pass, but like all things, these won't be 100% perfect. The checkers are pretty good these days though, particularly the application checkers (ie what ISV's use, not distros). (3) You might have hit an error or omission in the LSB. When such things are found, they are usually corrected in an erratum or something similar in the LSB itself. My understanding is that this is an infrequent event. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
