[Clfs-dev] startfile_prefix_spec

[DJ Lucas]

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.