[Clfs-dev] startfile_prefix_spec

[Joe Ciccone]

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 Ciccone