|
|
Log in / Subscribe / Register

Applications and bundled libraries in the Ideal World (LSB)

Applications and bundled libraries in the Ideal World (LSB)

Posted Mar 17, 2010 22:57 UTC (Wed) by vomlehn (guest, #45588)
Parent article: Applications and bundled libraries

In the ideal world, these compatibility issues would be dealt with by organizations such as the Linux Standard Base (LSB). To really make that work, however, requires a very agressive approach both to adding features and to developing and maintaining the test suites that would be required. I've heard of very few standards-type organizations that are funded for and capable of this kind of sustained effort. And asking for much funding in the open source world is an uphill battle, at best. (Disclaimer: I used to be a member of the LSB)


to post comments

Applications and bundled libraries in the Ideal World (LSB)

Posted Mar 18, 2010 9:30 UTC (Thu) by dgm (subscriber, #49227) [Link]

If LSB needs funding to work, I will _never_ work. That may very well explain why it has been largely ignored. Another approach is needed.

Maybe what we need is a scaled down start, attacking the worst actual problems first, and ignoring collateral -and irrelevant- issues like which package format is to be used.

Applications and bundled libraries in the Ideal World (LSB)

Posted Mar 18, 2010 21:07 UTC (Thu) by aleXXX (subscriber, #2742) [Link] (1 responses)

Last week I tried to rely on LSB 3.0 and it didn't work.
Maybe I did it wrong or I had wrong expectations.

So, I have a binary software built on SUSE 10 (SLES). Somewhere I found
that SUSE 10 is LSB 3.0 compatible.
So is RHEL 4/Centos 4, according to some webpage.
So I expected that the software built on SUSE 10 would also run on Centos
4. It didn't, it was expecting a symbol not present on Centos 4.

That symbol came from libstdc++, something in std::string, and it was
referenced by log4cplus. So I actually expected that log4cplus wouldn't
compile on Centos4, since there that symbol was missing, but it compiled
nevertheless successfully.

What was the reason ?
std::string has a lot of inline-functions, which call more or less
internal functions of libstdc++. Since they are inline, these calls to
internal functions end up in the resulting binary, instead of being
hidden in the binary libstdc++.

So what to do if you want to ship a binary application ?
Not sure. Link statically against libstdc++ ? Not too easy, as the web
told me.
Ship with a copy of libstdc++.so which works ? I tried, it seems to work.
But I'm not sure whether this doesn't have any other issues.

Use some other STL implementation, like STLport or stdcxx from Apache ?
Maybe, haven't tried yet.

Alex

Applications and bundled libraries in the Ideal World (LSB)

Posted Mar 18, 2010 22:14 UTC (Thu) by dlang (guest, #313) [Link]

look at what LSB defines. it only defines a very small portion of the system.

if the application only uses the things that are defined by LSB, then it would work on either distro.

but if the application uses things that are outside the scope of the LSB, then it may not work.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds