OK, it fails. And when I do
readelf -l a.out
and look at the output manually the interpreter line is just
[Requesting program interpreter: /lib/ld-linux-aarch64.so.1]
No /tools in there. How does it get there? I configured glib with
the little script
../configure --prefix=/tools --host=$LFS_TGT \
--build=$(../scripts/config.guess) --enable-kernel=3.2 \
--with-headers=/tools/include libc_cv_forced_unwind=yes \
Built it all, it failed the sanity test and I was trying to figure out
why. I thought --prefix only changed where something was installed, I
didn't know it got embedded. Maybe this is like argv. This is
referencing ld-linux on the host, not the one in /tools.
And my /tools symlink is right, I think:
up64$ ls -la / | grep tools
lrwxrwxrwx 1 root root 14 Jul 10 08:17 tools -> /mnt/lfs/tools
I don't think this relects an error in this glibc, more like something before.
But wait a minute, my cfg script may run with a different environment.
Don't think so though.
Tricks I've learned from a lot of unsuccessful builds in general: Put
the configure stuff in a little script so you can edit and run again
if needed. Redirect the output of configure or make into a file and
probably do a tail -f on that to watch. I have the configure output.
Running make over again.
No, I won't call it "climate change", do you have a "reality problem"? - AB1JX
Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach
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?
Q: What is the most annoying thing in e-mail?