LSB 2.0 and C++ [LWN.net]

LSB 2.0 and C++

Posted Aug 5, 2004 7:30 UTC (Thu) by fandom (subscriber, #4028)
Parent article: LSB 2.0 and C++

In the commercial world it seems to be quite usual to use computer
programs 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?

(Log in to post comments)

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 (subscriber, #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 (subscriber, #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.