On 09/06/2011, at 5:37 PM, Alexander Neundorf wrote: > On Thursday 09 June 2011, [email protected] wrote: >> 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. > > So, the only way to get LSB-compliant binaries is to use gcc and e.g. Intel > compilers are out of the game ?
Actually, no. You can make lsbcc invoke icc under the covers according to the LSB bug tracker: http://bugs.linuxbase.org/show_bug.cgi?id=1498 -- 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
