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.
_______________________________________________
Clfs-dev mailing list
[email protected]
http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org
