On 11/17/20 3:41 AM, Pierre Labastie via lfs-dev wrote:
On Tue, 2020-11-17 at 15:45 +0800, Kevin Buckley via lfs-dev wrote:
On Mon, 16 Nov 2020 at 14:49, Kevin Buckley <
kevin.m.buck...@gmail.com> wrote:
Pretty sure this will be an "end-user" issue but, just in case
anyone
has seen something similar and can thus point me in the right
direction,
I have seen this twice now, and i was more careful the second time.
(Note: following the Multilib Book, plus some PkgUser additons)
Get to the end of Chapter 7
Run test compile and readelf interrogations for all three "arch-s"
so
gcc dummy.c
gcc -m32 dummy.c
gcc -mx32 dummy.c
Deep joy.
Exit chroot and umount bind mouted FSes
Backup temporary system
Remount bind mouted FSes
Re-enter chroot
Try to perform a simple
gcc dummy.c
Deep sorrow!
Output from the failed compilation suggest that there's a crtN.o
file, with a GlibC version that has come from the host, being
pulled in.
Thought I'd chuck in the actual error message in case it rings any
bells
for anyone.
GNU C17 (GCC) version 10.2.0 (x86_64-lfs-linux-gnu)
compiled by GNU C version 10.2.0, GMP version 6.2.0, MPFR
version 4.1.0,
MPC version 1.2.0, isl version isl-0.22.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-
heapsize=131072
Compiler executable checksum: d384610cfa11eec261f14798a7f678e4
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../x86_64-lfs-
linux-gnu/bin/a
s -v --64 -o /tmp/cc6W4Vah.o /tmp/ccvqsYQf.s
GNU assembler version 2.35 (x86_64-lfs-linux-gnu) using BFD version
(GNU Binutil
s) 2.35
COMPILER_PATH=/usr/libexec/gcc/x86_64-lfs-linux-
gnu/10.2.0/:/usr/libexec/gcc/x86
_64-lfs-linux-gnu/10.2.0/:
/usr/libexec/gcc/x86_64-lfs-linux-gnu/:
/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/:
/usr/lib/gcc/x86_64-lfs-linux-gnu/:
/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../x86_64-lfs-
linux-gnu/bin/
LIBRARY_PATH=/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/:
/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../x86_64-lfs-
linux-gnu/lib/../lib/:
/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../lib/:
/lib/../lib/:
/usr/lib/../lib/:
/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../x86_64-lfs-
linux-gnu/lib/:
/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../:/lib/:
/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-lfs-linux-gnu/10.2.0/collect2 -plugin
/usr/libexec/gcc/x86_64-lfs-linux-gnu/10.2.0/liblto_plugin.so
-plugin-opt=/usr/libexec/gcc/x86_64-lfs-linux-gnu/10.2.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/cctzwl1f.res
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_x86_64
-dynamic-linker /lib64/ld-linux-x86-64.so.2
/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../lib/crt1.o
/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../lib/crti.o
/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/crtbegin.o
-L/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0
-L/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../x86_64-lfs-
linux-gnu/lib/../lib
-L/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../lib -
L/lib/../lib
-L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../x86_64-lfs-
linux-gnu/lib
-L/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../.. /tmp/cc6W4Vah.o
-lgcc --push-state --as-needed -lgcc_s --pop-state
-lc -lgcc --push-state --as-needed -lgcc_s --pop-state
/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/crtend.o
/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../lib/crtn.o
/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../x86_64-lfs-
linux-gnu/bin/ld:
/usr/lib/gcc/x86_64-lfs-linux-
gnu/10.2.0/../../../../lib/crt1.o(.text+0x26):
unresolvable R_X86_64_NONE relocation against symbol
`__libc_start_main@@GLIBC_2.2.5'
collect2: error: ld returned 1 exit status
Yes, I've seen this. It had something to do with stripping (so 1st
question is: did you strip binaries? Old versions (don't ask the
version, something around 2.28 IIRC) of strip do not recognize some
R_X86_64_xxx relocation items and replace them with R_X86_64_NONE,
which makes the symbol undefined...
The cure is to use $LFS/usr/bin/strip for stripping. I'd say we should
put that in the instructions, actually, or change binutils requirement
to the first version which works.
I am in favor of just removing the strip section in Chapter 7. Saving
90 MB is not really significant for today's HW. We say that the user
should have at least 5 GB free, so 90 MB is less than 2% of that.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
