Andrew Benton wrote: > On Mon, 27 Feb 2012 20:10:28 -0800 Bryan Kadzban > <br...@kadzban.is-a-geek.net> wrote: >> >> Specifically, section 5.2.1. > > In practice it works fine and causes no problems. I have everything > in /lib with no lib64 symlinks. It makes a simpler and more > straightforward directory structure.
See, I disagree with that. IMO "32-bit ld-linux in the standard place it always was, 64-bit ld-linux in the new directory" makes far more sense. The *only* case where the 64-bit ld-linux makes any sense at all in the /lib directory is on a pure64 machine (which I can't run anyway, see below), *and* when no already-built binaries are being used (which also doesn't apply to me: I regularly run ancient games built from the Loki installer, back when they were around). >> Hacking around that in *any* way is not, IMO, a good idea. It also >> forces me to deviate from the LFS book even more than I do now, >> since I require multilib. > > Multilib is only of use if you want to run legacy binaries such as > windows programs with wine. Yes, exactly. Which I do, fairly frequently: the original HL, Unreal, C&C: Red Alert 1, etc. Plus (native Linux 32-bit) UT, Descent 3, RtCW, Doom 3, etc. Many different games, none of which provide sources. Which means my system *must* be multilib, and *must* conform to the old x86 32-bit ABI, including the location of the 32-bit dynamic linker. Now, the 64-bit dynamic linker is a bit less of a problem -- but why hack around the obvious upstream x86_64 system defaults, not to mention the SysV ABI, just to look, in some people's opinions, slightly cleaner -- an opinion I don't share? :-) (This is also the biggest thing I don't like about Debian, for what little that's worth...) Jeremy Huntwork wrote: > On 2/27/12 11:10 PM, Bryan Kadzban wrote: >> Specifically, section 5.2.1. > > Interestingly, it says there: > > ---- > There is one valid program interpreter for programs conforming to the > AMD64 ABI: > > /lib/ld64.so.1 > However, Linux puts this in > > /lib64/ld-linux-x86-64.so.2 > ---- > > To me, that reads that the standard is "/lib/ld64.so.1" but Linux > does something different and puts in "/lib64/ld-linux-x86-64.so.2" Right, but the standard says nothing at all about using the path "/lib/ld-linux-x86-64.so.2". There's no possible way that will work with anything. :-) (In fact, it might make sense to propose moving the linker to -- or symlinking it from -- /lib/ld64.so.1 instead of what glibc and binutils currently do. Unfortunately my track record trying to get changes into glibc is ... not great. So I haven't tried it.) Bruce Dubbs wrote: > I agree that it looks funny. Also, I use an Intel 64 bit system, not > AMD. What should it be for me? Your Intel-made chip implements the AMD64 ABI. AMD came up with the opcodes, memory management interfaces, etc., and called the result "AMD64". Intel copied it after Itanium tanked, and called it "EM64T". Subsequent references to this architecture have tended to use x86-64, to try to avoid some of the confusion. It seems the SysV ABI has not been changed to use that name.
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
