[Clfs-dev] startfile_prefix_spec

[DJ Lucas]

On 02/02/2011 11:24 PM, DJ Lucas wrote:
> 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. 
Never mind that, I answered my own question, no bug. Upon further 
reading, IIUC, *multilib_defaults is m64 so the first case is never used 
(is <blank> the correct option for the first case?). If that is correct 
the path could be /usr/share/, /usr/bin/, or 
/usr/<insert_any_existing_directory_here>/, as long as it makes the 
relative path work. So there is no error, however, see the next question 
below...
> 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?

The related question:

Why not:
----------
*multilib:
. !m64 !m32;64:lib64 m64 !m32;32:lib !m64 m32;
----------
*multilib_defaults:
m64
----------
*startfile_prefix_spec:
/usr/
----------

?

I've been digging and I can't find a good reason why the relative paths 
are used. I had suspected that it dates back to the original addition of 
*startfile_prefix_spec (early multilib days?), but have found nothing as 
for why. A good rationale could probably result in some nice explanatory 
text in both CLFS and LFS as a result if anybody has an answer.

-- DJ Lucas



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