Frans de Boer wrote:
On 20-12-16 21:56, Bruce Dubbs wrote:
Frans de Boer wrote:
Hi all,
I just noticed that there are changes in the development version of LFS,
related to x86_64 architecture. But i do miss the rationale and/or more
explanation. The latter is important because I see several changes which
make sense, but misses other related changes in various other packages.
Also having now /lib64 as a directory instead of a link puzzles me. The
more because /lib is still a directory and not a link to /lib64 as per
FHS
3.0.
Where does FHS 3.0 say a symlink is required?
What additional explanation would you suggest and where should it be?
Looking at the FHS 3.0 documentation does not help either since the new
LFS directory structure seems to be a non-consistent mix of various
possibilities. See above and next example: /usr/lib with redundant link
/usr/lib64.
4.8. /usr/lib<qual> : Alternate format libraries (optional)
does not seem to require /usr/lib64.
Footnote 13 makes an implicit reference to it. But I admit, it's not a
very strong point.
However, it seems not consistent to have /usr/lib and in the root /lib64.
Use of qualifiers is - as I read it - only meant to be use by
multi-library systems, which LFS explicitly states currently that it is not.
That's right, but there are apps that hard code some assumptions so /lib64
with its two symlinks is a workaround. If we could reliably remove it, we
would.
Also, I never implied that having /lib64 does require /usr/lib64 - simply
because there is no hard relation between them or their content. It's just
what I stated above, inconsistent use of qualifiers.
OK, but we do't need /usr/lib64 and not having it makes things easier for
us (for the most part).
By the way: Having /lib64 and /usr/lib64 as links to their respective lib
directory make sense only when using third party (binary) packages.
Agree for the most part. Some packages require a patch to avoid the need
and finding where the changes are needed is often difficult.
Finally on the matter of explanation: sure, I can write one and find a
place to put it up. But we first need to get into the "inconsistency"
issue to be able to make a coherent and justifiable explanation.
As I said, it is a workaround. I'd prefer that it was not needed.
Even with our changes, look at the adjsuting page in Chapter 6:
echo 'int main(){}' > dummy.c
cc dummy.c -v -Wl,--verbose &> dummy.log
readelf -l a.out | grep ': /lib'
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
I'm not sure if that /lib64 is in glibc or binutils (probably glibc), but
it would need to be fixed to remove /lib64.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
