On Sat, 2020-06-20 at 14:20 +0200, Frans de Boer wrote:
> On 20-06-2020 13:12, Xi Ruoyao wrote:
> > On 2020-06-20 13:02 +0200, Frans de Boer wrote:
> > > On 19-06-2020 22:33, Frans de Boer wrote:
> > > > On 19-06-2020 22:15, Pierre Labastie wrote:
> > > > > On Fri, 2020-06-19 at 21:13 +0200, Frans de Boer wrote:
> > > > > > Dear all,
> > > > > >
> > > > > > I follow every step but always stumble on the '$LFS_TGT-gcc
> > > > > > dummy.c'
> > > > > > -
> > > > > > in the first glibc.c section - in that crti.o can't be
> > > > > > located by ld.
> > > > > > Looking for crti.o, I find it residing in the
> > > > > > $LFS/usr/lib64
> > > > > > directory.
> > > > > That's the weird thing, /usr/lib64 shouldn't exist. It's the
> > > > > setting of
> > > > > libc_cv_slibdir, which prevents that.
> > > > >
> > > > > > So, why can't ld find it?
> > > > > gcc has been told (with the "case" instruction) to ask ld to
> > > > > look into
> > > > > /usr/lib, not /usr/lib64.
> > > > >
> > > > > Pierre
> > > > >
> > > > I will check if the sed was successful.
> > > >
> > > > --- Frans.
> > > >
> > > I checked and the result of the sed was as expected. Only glibc
> > > creates
> > > the usr/lib64 directory.
> > >
> > > In the past the /usr/lib64 directory was a link to /usr/lib.
> > > Also, due
> > > to experimenting, I also found in the past that for some
> > > adaptations I
> > > needed to execute next for glibc:
> > >
> > > # When going for a specific architecture, change some literals
> > > /lib into
> > > /lib64 or /lib32
> > > #
> > > if [[ ilibType -eq elibTYPE_LIB && $bldTARCH == "x86_64" ]]; then
> > > #
> > > # Change literal /lib64 into /lib with no architecture depended
> > > directories
> > > sed -r -i -e 's@(/lib)64(/ld-linux)@\1\2@'
> > > ./sysdeps/unix/sysv/linux/x86_64/ldconfig.h
> > > sed -i -e 's@6, "/lib64", 6@4, "/lib", 4@' \
> > > -e 's@len >= 6 \&\& ! memcmp @len >= 4 \&\& !
> > > memcmp @'
> > > ./sysdeps/unix/sysv/linux/x86_64/dl-cache.h
> > > sed -r -i -e 's@(lib)64@\1@g'
> > > ./sysdeps/unix/sysv/linux/x86_64{,/64}/configure{,.ac}
> > > # sed -i -e 's@die "ldd execution failed" if $?;@# &@'
> > > ./scripts/test-installation.pl
> > > sed -r -i -e 's@(RTLDLIST=.*\\2)64@\1@'
> > > ./sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
> > > fi
> > > -------
> > >
> > > The above (maybe somewhat dated) is an example when NOT having
> > > the
> > > /usr/lib64 directory, either as link or directory. So, it is
> > > clear - so
> > > it seems - that we need some more tuning, or revert to having
> > > /usr/lib64
> > > as just a link.
> > I don't think so.
> >
> > The code automatically choose "${exec_prefix}/lib64" is in glibc-
> > 2.31/sysdeps/unix/sysv/linux/x86_64/64/configure. It's very clear
> > that if
> > "libc_cv_slibdir" is explicitly set, the code won't be executed.
> >
> > So I believe you forgot to set "libc_cv_slibdir=/lib", maybe by a
> > typo (like
> > "libc_cv_libdir=/lib").
> >
> > > Suggestions?
>
> Nope, here a partial copy:
> .....
> --with-headers=$LFS/usr/include \
> libc_cv_slibdir=/lib
>
The only thing I can tell you is that I have built lfs with the new
"cross" approach zillion times (for testing) using commands exactly as
they are written, and the /usr/lib64 dir has never been created.
Maybe look at config.log (or post it) to see where the issue comes from
in your build.
Pierre
--
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
