Mike Hearn wrote:
I'm not aware of e.g. an LSB-1.3 application that doesn't run properly on any system that supports LSB-1.3. Are you?
I'm not aware of any LSB applications at all, actually. But let's take RealPlayer for example. Let's pretend that Real had made it an LSB app.
Would that have saved it from being broken by NPTL. No. LSB doesn't specify (as far as I'm aware) that LSB apps must be linked against LinuxThreads.
Bzzt. In the real world, the distro vendor would have noticed this during LSB certification, and since the shared library loader for LSB 1.3 is /lib/ld-lsb.so.1 rather than /lib/ld-linux.so.2, the vendor can easily force libc to be linuxthreads based even if the default libc is NPTL based.
I believe that as people start building LSB-compliant apps, they'll find it quite a useful way to avoid having to package ten different flavors of their apps just to be compatible. It's going to be a lot easier with LSB 3.0, since by that time the C++ ABI will have settled down, but I do think even LSB 2.0 is worth looking at for some applications.
Yes, I know, you'll probably want to post something bitter and negative about LSB in response, but I'm going to put my hands over my ears and go "la la la", so I won't notice whether you actually do :-) - Dan
Dan Kegel wrote:
Bzzt. In the real world, the distro vendor would have noticed this during LSB certification, and since the shared library loader for LSB 1.3 is /lib/ld-lsb.so.1 rather than /lib/ld-linux.so.2, the vendor can easily force libc to be linuxthreads based even if the default libc is NPTL based.
For the record, I checked, and Red Hat 9's lsb-1.3 package simply made ld-lsb.so.1 a symlink to ld-linux.so.2, so that version of their lsb environment does seem to use NPTL. Probably they figured they'd do something fancier if they got any complaints, and since nobody was shipping LSB-1.3 apps, they never had to.
It'll be interesting to see if LSB-2.0 apps actually get deployed... having an argument about hypothetical pros and cons is a bit sterile. - Dan
On Sun, 21 Nov 2004 15:01:58 -0800, Dan Kegel wrote:
For the record, I checked, and Red Hat 9's lsb-1.3 package simply made ld-lsb.so.1 a symlink to ld-linux.so.2,
I'm pretty sure all distros do that. I've never heard of any LSB compliant distro using a custom linker to override upstream choices, even though it's theoretically possible. I suspect most distro developers just don't care - if they cared about stability they would not have shipped NPTL as the default at all, for any app. On a desktop system at any rate there's little to no benefit for existing software. The performance improvements are only really an issue for servers.
so that version of their lsb environment does seem to use NPTL. Probably they figured they'd do something fancier if they got any complaints, and since nobody was shipping LSB-1.3 apps, they never had to.
There's that catch-22 again. No LSB apps == LSB has no influence.
It'll be interesting to see if LSB-2.0 apps actually get deployed... having an argument about hypothetical pros and cons is a bit sterile.
Well, they aren't really hypothetical. The cons of todays LSB is I believe why there aren't any LSB apps out there today. I hope it goes somewhere but I'm not holding my breath, not any more.
-
Dan Kegel -
Mike Hearn