[Clfs-dev] startfile_prefix_spec

DJ Lucas dj at linuxfromscratch.org
Wed Feb 2 21:24:19 PST 2011


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?

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/
----------

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 :-) ).

-- DJ Lucas

-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.




More information about the Clfs-dev mailing list