Thinking forward LFS-7.0
bryan at kadzban.is-a-geek.net
Mon Mar 14 21:26:44 PDT 2011
Bruce Dubbs wrote:
>>> * Multi-lib - Shunned previously, but there are many projects
>>> that expect this environment.
>> For people who build from source, which projects *expect* multilib
>> on x86_64 ?
>> I will agree that building a bi-arch desktop (that is, both 32-bit
>> and 64-bit Xorg, with some applications as 32-bit and others as
>> 64-bit), was a very educational exercise when I did it. That was
>> back in the gnome-2.1x days - the real fun was in making some parts
>> of gnome 32-bit and others 64-bit). Fun, but pointless. On
>> x64_64, modern software runs fine as 64-bit.
> This pretty much fits into the same category as above. The only
> reason for lib64 to exist is for those proprietary packages that have
> not been updated for 64-bit operation.
...Or binaries from anywhere else. Since the official 32-bit ABI
*requires* the dynamic linker to be at path /lib/ld-linux.so.2 (to
remain compatible with pre-64-bit Linux systems), and the official
64-bit ABI *requires* the dynamic linker to be at path
Now, that only applies if you're running binaries and not source, yes.
But every second or third week I'll fire up one of the Id games, or UT,
or Unreal, or Descent 3. (Sure, they're old. But they still work, and
they're native binaries that are unavailable as source. :-) Well,
except for a couple of the Id ones anyway.)
Yes, you're right; this isn't for very many packages. But it's also
less of a pain to do it this way (because the *default* behavior of
gcc/glibc is to do the Right Thing already, because by default they
*have* to follow the ABIs); the only thing that suffers is a sense of
what's cleaner. (And by this point, given the backward compatibility
constraints, I've decided that it's cleaner to stick to the standard
ABIs. :-) )
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 261 bytes
Desc: OpenPGP digital signature
More information about the lfs-dev