> > Thinly veiled flames are not conducive to getting people to
> > volunteer to help you.
>
> Sorry you felt flamed. Wasn't my intention.
Apologies. Written text is a lousy language for the non-verbal
part of communication. The LSB comment read to me as being faux
"polite", and this will annoy me greatly. The fact that LSB is being
used as a justification for what appears to be broken behavior doesn't
help.
> It doesn't exactly say that, but its requirements for 32 bit binaries
> and 64 bit binaries conflict, if I remember well. Like they both can
> expect their libraries to dlopen() to be in /usr/lib/ or something
> like that. Only on some 64 bit architectures. Not all of them. I don't
> remember the details.
This is not a conflict given engineering effort. 32 bit binaries
and 64 bit binaries are distinguishable from one another, and your
kernel can take appropriate steps to get them to coexist. It might
help you to remember that amd64 is not the first platform to have
these sorts of issues; sparcv9 is a decade old and presented similar
problems with sparcv8 executables.
NetBSD's techniques for dealing with this is one example of how to
work around the problems. Only truly native binaries get the obvious
treatment for accessing the filesystem. Other emulation targets
(where a 32 bit binary on a 64 bit system is considered an emulation
target, as is a.out on an ELF system) has its path lookup process
intefered with. Opening /usr/lib/libcurses.so will actually attempt
to open /emul/$foo/usr/lib/libncurses.so before trying the root of the
filesystem ($foo being something appropriate for the binary type, like
linux, netbsd32, aout, ibcs2, svr4_32, etc).
So a linux binary can be presented with the libraries it needs
without interfering with others; not to mention extending to other
issues like incomptability between ld.so.conf formats. It's not
perfect, but it does let you move on.
> You are doing one subset of users a disservice and another set of
> users a service: Those that want to run binaries not specifically
> prepared for your distribution, but against the standard.
I get to have my cake and eat it too and expect no less when the
underlying capability is a simple matter of engineering. My web
browser is a linux binary expecting an LSB compliant system. My
system isn't LSB compliant and has no hope of doing so in reality.
But my web browser sees LSB.
|