On 02/03/2011 07:30 AM, Joe Ciccone wrote:
On 02/03/2011 12:24 AM, DJ Lucas wrote:
I'm currently working my way through CLFS and making modifications to
use /lib32 for 32bit and /lib for 64bit with a lib64 symlink (Debian
style) so I'm reading a lot, crossing my Is and dotting my Ts, and
wanted to make sure I understand the specs file adjustment correctly.
I think I might have happened upon an error in the book, but I'm not
sure - my understanding might just be completely borked. Currently in
CLFS Multilib x86_64 gcc specs file we have these snipits:
----------
*multilib:
. !m64 !m32;64:../lib64 m64 !m32;32:../lib !m64 m32;
----------
*startfile_prefix_spec:
/usr/lib/
----------
IIUC, it seems to me that startfile_prefix_spec should be defined as
/usr/lib64 on x86_64 in CLFS, as the relative path used is "." if no
-m flags are supplied. I'm trying to wrap my head around multi-lib and
how all of the pieces fit together. Does ld later override these
paths, or am I completely missing the point here? Is there some
justification for using /usr/lib that I haven't found yet?
I do not believe there is an issue in the book. We don't actually set
the startfile_prefix_spec in the final system. In the temp system it
always uses the relative paths regardless of the base path.
Here is the output from a standard build on multilib from /tools after
the specs modification:
# ./gcc --print-file-name=crti.o -m32
/usr/lib/../lib/crti.o
# ./gcc --print-file-name=crti.o -m64
/usr/lib/../lib64/crti.o
And on the final system (No specs modification):
# gcc --print-file-name=crti.o -m32
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib/crti.o
# gcc --print-file-name=crti.o -m64
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib64/crti.o
In my own specs, after adjustment, I have the following snipits (which
seem correct, though I haven't dared to move on just yet in case my
understanding is not):
----------
*multilib:
. !m64 !m32;64:../lib m64 !m32;32:../lib32 !m64 m32;
----------
*startfile_prefix_spec:
/usr/lib/
----------
This appears to be correct, however I do not believe you need to
startfile_prefix_spec to be set at all. We only are required to set this
during our toolchain modification because we specifically set this to
/tools earlier in the build. In your case it should already be pointing
in the general direction of /usr.
OT: FYI, the goal for this build is a 64bit OS with just enough 32bit
libs around to use the prebuilt arm-eabi cross toolchain that ships in
the android source tree (as opposed to using my own hacked up version
of the Code Sourcery arm toolchain which has proven to be less than
fun making it play nicely--IOW I've been at it for a while and it
hasn't worked yet). If it pans out, and if there is any interest, I'm
keeping a log of changes I made to the build (already partially in
wiki format at that because I happen to like the {{{ }}} dividers :-) ).
Out of curiosity does the android source tree have it's ld.so at
/lib{,32}/ld-linux.so.2 or /lib{,64}/ld-linux-x86_64.so.2. Just some
food for thought, If that guy is in the wrong place you could be doing
all this work for nothing. I know a simple symlink could fix it, but
I've always tried to do without.
Joe, thanks for the quick reply and detailed explanation. Yes I was
referring to the gcc adjustment at the beginning of chapter 7 (before
GCC is rebuilt). I had actually done the specs change in Chapter 6
manually without giving it a second thought. Once I realized exactly why
this was being done, the red flag went up. As for android, yes the tools
reference /lib/ld-linux.so.2, but I've been meaning to do this for a
while. For my minimal purposes, I could probably do a pure64 build and
just copy /lib from a working 32bit build to /lib32, create the symlink
to ld-linux.so.2, and add /lib32 to ld.so.conf (and maybe some abuse of
LD_PRELOAD or LD_LIBRARY_PATH), but I wouldn't learn anything that way.
By explicitly deviating from the books instructions, I have to first
understand every change, to do that, I have to read more, and then make
sure I have it correct in my environment, else stuff will be broken.
Just my twisted method. :-)
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
_______________________________________________
Clfs-dev mailing list
[email protected]
http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org
