Re: [lfs-support] Chroot Path Problem for Python
On Mon, Dec 30, 2019 at 08:55:52AM +0100, Pierre Labastie wrote: > Le 30/12/2019 à 07:17, Bruce Dubbs a écrit : > > On 12/29/19 10:41 PM, Alan Feuerbacher wrote: > >> > >> On 12/29/2019 4:28 PM, Bruce Dubbs wrote: > >>> On 12/29/19 4:57 PM, Ken Moffat wrote: > On Sun, Dec 29, 2019 at 09:02:34PM +, Ken Moffat wrote: > > On Sun, Dec 29, 2019 at 01:40:17PM -0600, Bruce Dubbs wrote: > >> On 12/29/19 12:03 PM, Alan Feuerbacher wrote: > >>> On 12/29/2019 9:35 AM, Bruce Dubbs wrote: > On 12/29/19 9:45 AM, Alan Feuerbacher wrote: > > Perhaps, before building python in /tools, > ln -sv libcrypt.so.1 /tools/libcrypt.so.2 > (just a suggestion, I've no way of testing it) > >>> > >>> I don't see that. Glibc-2.30 in section 5.7 should create libcrypt.so.1 > >>> in > >>> /tools/lib. > > Did I typo it ? My intention is that /tools/libcrypt.so.2 should exist, and point to .so.1. > >> I'm building with Fedora 31. > > > > Alan, that doesn't make any difference. We are building with our own > > source. > > Nothing in /tools should be from the host distro. > > > > Hmmm, except if the Python build system somehow uses the library on the host > (nightmare coming again?)... > > Pierre That's what I'm thinking. And if after going back into /tools and rebuilding python the immediate problem is solved (ldd in chapter 6) it will be necessary to stop after python in chapter 6 (assuming that builds) to see what it links to. ĸen -- We've all got both light and dark inside of us. What matters is the part we choose to act on. -- Sirius Black -- 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
Re: [lfs-support] Chroot Path Problem for Python
Le 30/12/2019 à 08:55, Pierre Labastie a écrit : > Le 30/12/2019 à 07:17, Bruce Dubbs a écrit : >> On 12/29/19 10:41 PM, Alan Feuerbacher wrote: >>> >>> On 12/29/2019 4:28 PM, Bruce Dubbs wrote: On 12/29/19 4:57 PM, Ken Moffat wrote: > On Sun, Dec 29, 2019 at 09:02:34PM +, Ken Moffat wrote: >> On Sun, Dec 29, 2019 at 01:40:17PM -0600, Bruce Dubbs wrote: >>> On 12/29/19 12:03 PM, Alan Feuerbacher wrote: On 12/29/2019 9:35 AM, Bruce Dubbs wrote: > On 12/29/19 9:45 AM, Alan Feuerbacher wrote: > > What do you get for "ldd /tools/bin/python3" ? > > -- Bruce (lfs chroot) root:/tools/bin# ldd /tools/bin/python3 linux-vdso.so.1 (0x7ffcc9e82000) libcrypt.so.2 => not found libpthread.so.0 => /tools/lib/libpthread.so.0 (0x7f8eaa69b000) libdl.so.2 => /tools/lib/libdl.so.2 (0x7f8eaa696000) libutil.so.1 => /tools/lib/libutil.so.1 (0x7f8eaa691000) libm.so.6 => /tools/lib/libm.so.6 (0x7f8eaa54e000) libc.so.6 => /tools/lib/libc.so.6 (0x7f8eaa39) /lib64/ld-linux-x86-64.so.2 => /tools/lib64/ld-linux-x86- 64.so.2 (0x7f8eaa6be000) >>> >>> 'libcrypt.so.2 => not found' is enough to prevent the application from >>> running. libcrypt.so.1 should have been installed by glibc. I do not >>> know >>> why python is looking for libcrypt.so.2. Is that from your host? >>> >> >> Is Alan building on fedora-30 or later ? >> >> A gurgle for libcrypt.so.2 found >> https://bugzilla.redhat.com/show_bug.cgi?id=1666033 >> >> Apparently fedora have moved to libxcrypt. There is a >> libxcrypt-compat package which installs libcrypt.so.1. >> Whether installing that on the host will help for LFS >> I have no idea, but I suspect it won't be that simple. >> >> Looking at https://github.com/pypa/manylinux/issues/305 >> I suspect that this might be problematic. But probably >> only for python. >> >> And the reasoning for the change is at >> https://fedoraproject.org/wiki/Changes/FullyRemoveDeprecatedAndUnsafeFunctionsFromLibcrypt >> >> >> ĸen > > Perhaps, before building python in /tools, > ln -sv libcrypt.so.1 /tools/libcrypt.so.2 > (just a suggestion, I've no way of testing it) I don't see that. Glibc-2.30 in section 5.7 should create libcrypt.so.1 in /tools/lib. >> >>> I'm building with Fedora 31. >> >> Alan, that doesn't make any difference. We are building with our own >> source. >> Nothing in /tools should be from the host distro. >> > > Hmmm, except if the Python build system somehow uses the library on the host > (nightmare coming again?)... > Hopefully not: I've tried a jhalfs build on fedora 31, and python3 is linked to libcrypt.so.1. So, I think that something went wrong when the OP compiled python in chapter 5 (either the lfs environment was not set, or something was wrong in that environment). 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
Re: [lfs-support] Chroot Path Problem for Python
Le 30/12/2019 à 07:17, Bruce Dubbs a écrit : > On 12/29/19 10:41 PM, Alan Feuerbacher wrote: >> >> On 12/29/2019 4:28 PM, Bruce Dubbs wrote: >>> On 12/29/19 4:57 PM, Ken Moffat wrote: On Sun, Dec 29, 2019 at 09:02:34PM +, Ken Moffat wrote: > On Sun, Dec 29, 2019 at 01:40:17PM -0600, Bruce Dubbs wrote: >> On 12/29/19 12:03 PM, Alan Feuerbacher wrote: >>> On 12/29/2019 9:35 AM, Bruce Dubbs wrote: On 12/29/19 9:45 AM, Alan Feuerbacher wrote: What do you get for "ldd /tools/bin/python3" ? -- Bruce >>> >>> (lfs chroot) root:/tools/bin# ldd /tools/bin/python3 >>> linux-vdso.so.1 (0x7ffcc9e82000) >>> libcrypt.so.2 => not found >>> libpthread.so.0 => /tools/lib/libpthread.so.0 >>> (0x7f8eaa69b000) >>> libdl.so.2 => /tools/lib/libdl.so.2 (0x7f8eaa696000) >>> libutil.so.1 => /tools/lib/libutil.so.1 (0x7f8eaa691000) >>> libm.so.6 => /tools/lib/libm.so.6 (0x7f8eaa54e000) >>> libc.so.6 => /tools/lib/libc.so.6 (0x7f8eaa39) >>> /lib64/ld-linux-x86-64.so.2 => /tools/lib64/ld-linux-x86- >>> 64.so.2 (0x7f8eaa6be000) >>> >> >> 'libcrypt.so.2 => not found' is enough to prevent the application from >> running. libcrypt.so.1 should have been installed by glibc. I do not >> know >> why python is looking for libcrypt.so.2. Is that from your host? >> > > Is Alan building on fedora-30 or later ? > > A gurgle for libcrypt.so.2 found > https://bugzilla.redhat.com/show_bug.cgi?id=1666033 > > Apparently fedora have moved to libxcrypt. There is a > libxcrypt-compat package which installs libcrypt.so.1. > Whether installing that on the host will help for LFS > I have no idea, but I suspect it won't be that simple. > > Looking at https://github.com/pypa/manylinux/issues/305 > I suspect that this might be problematic. But probably > only for python. > > And the reasoning for the change is at > https://fedoraproject.org/wiki/Changes/FullyRemoveDeprecatedAndUnsafeFunctionsFromLibcrypt > > > ĸen Perhaps, before building python in /tools, ln -sv libcrypt.so.1 /tools/libcrypt.so.2 (just a suggestion, I've no way of testing it) >>> >>> I don't see that. Glibc-2.30 in section 5.7 should create libcrypt.so.1 in >>> /tools/lib. > >> I'm building with Fedora 31. > > Alan, that doesn't make any difference. We are building with our own source. > Nothing in /tools should be from the host distro. > Hmmm, except if the Python build system somehow uses the library on the host (nightmare coming again?)... 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
Re: [lfs-support] Chroot Path Problem for Python
On 12/29/19 10:41 PM, Alan Feuerbacher wrote: On 12/29/2019 4:28 PM, Bruce Dubbs wrote: On 12/29/19 4:57 PM, Ken Moffat wrote: On Sun, Dec 29, 2019 at 09:02:34PM +, Ken Moffat wrote: On Sun, Dec 29, 2019 at 01:40:17PM -0600, Bruce Dubbs wrote: On 12/29/19 12:03 PM, Alan Feuerbacher wrote: On 12/29/2019 9:35 AM, Bruce Dubbs wrote: On 12/29/19 9:45 AM, Alan Feuerbacher wrote: What do you get for "ldd /tools/bin/python3" ? -- Bruce (lfs chroot) root:/tools/bin# ldd /tools/bin/python3 linux-vdso.so.1 (0x7ffcc9e82000) libcrypt.so.2 => not found libpthread.so.0 => /tools/lib/libpthread.so.0 (0x7f8eaa69b000) libdl.so.2 => /tools/lib/libdl.so.2 (0x7f8eaa696000) libutil.so.1 => /tools/lib/libutil.so.1 (0x7f8eaa691000) libm.so.6 => /tools/lib/libm.so.6 (0x7f8eaa54e000) libc.so.6 => /tools/lib/libc.so.6 (0x7f8eaa39) /lib64/ld-linux-x86-64.so.2 => /tools/lib64/ld-linux-x86- 64.so.2 (0x7f8eaa6be000) 'libcrypt.so.2 => not found' is enough to prevent the application from running. libcrypt.so.1 should have been installed by glibc. I do not know why python is looking for libcrypt.so.2. Is that from your host? Is Alan building on fedora-30 or later ? A gurgle for libcrypt.so.2 found https://bugzilla.redhat.com/show_bug.cgi?id=1666033 Apparently fedora have moved to libxcrypt. There is a libxcrypt-compat package which installs libcrypt.so.1. Whether installing that on the host will help for LFS I have no idea, but I suspect it won't be that simple. Looking at https://github.com/pypa/manylinux/issues/305 I suspect that this might be problematic. But probably only for python. And the reasoning for the change is at https://fedoraproject.org/wiki/Changes/FullyRemoveDeprecatedAndUnsafeFunctionsFromLibcrypt ĸen Perhaps, before building python in /tools, ln -sv libcrypt.so.1 /tools/libcrypt.so.2 (just a suggestion, I've no way of testing it) I don't see that. Glibc-2.30 in section 5.7 should create libcrypt.so.1 in /tools/lib. I'm building with Fedora 31. Alan, that doesn't make any difference. We are building with our own source. Nothing in /tools should be from the host distro. -- 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
Re: [lfs-support] Chroot Path Problem for Python
On 12/29/2019 4:28 PM, Bruce Dubbs wrote: On 12/29/19 4:57 PM, Ken Moffat wrote: On Sun, Dec 29, 2019 at 09:02:34PM +, Ken Moffat wrote: On Sun, Dec 29, 2019 at 01:40:17PM -0600, Bruce Dubbs wrote: On 12/29/19 12:03 PM, Alan Feuerbacher wrote: On 12/29/2019 9:35 AM, Bruce Dubbs wrote: On 12/29/19 9:45 AM, Alan Feuerbacher wrote: What do you get for "ldd /tools/bin/python3" ? -- Bruce (lfs chroot) root:/tools/bin# ldd /tools/bin/python3 linux-vdso.so.1 (0x7ffcc9e82000) libcrypt.so.2 => not found libpthread.so.0 => /tools/lib/libpthread.so.0 (0x7f8eaa69b000) libdl.so.2 => /tools/lib/libdl.so.2 (0x7f8eaa696000) libutil.so.1 => /tools/lib/libutil.so.1 (0x7f8eaa691000) libm.so.6 => /tools/lib/libm.so.6 (0x7f8eaa54e000) libc.so.6 => /tools/lib/libc.so.6 (0x7f8eaa39) /lib64/ld-linux-x86-64.so.2 => /tools/lib64/ld-linux-x86- 64.so.2 (0x7f8eaa6be000) 'libcrypt.so.2 => not found' is enough to prevent the application from running. libcrypt.so.1 should have been installed by glibc. I do not know why python is looking for libcrypt.so.2. Is that from your host? Is Alan building on fedora-30 or later ? A gurgle for libcrypt.so.2 found https://bugzilla.redhat.com/show_bug.cgi?id=1666033 Apparently fedora have moved to libxcrypt. There is a libxcrypt-compat package which installs libcrypt.so.1. Whether installing that on the host will help for LFS I have no idea, but I suspect it won't be that simple. Looking at https://github.com/pypa/manylinux/issues/305 I suspect that this might be problematic. But probably only for python. And the reasoning for the change is at https://fedoraproject.org/wiki/Changes/FullyRemoveDeprecatedAndUnsafeFunctionsFromLibcrypt ĸen Perhaps, before building python in /tools, ln -sv libcrypt.so.1 /tools/libcrypt.so.2 (just a suggestion, I've no way of testing it) I don't see that. Glibc-2.30 in section 5.7 should create libcrypt.so.1 in /tools/lib. -- Bruce I'm building with Fedora 31. Alan -- 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
Re: [lfs-support] Chroot Path Problem for Python
On 12/29/19 4:57 PM, Ken Moffat wrote: On Sun, Dec 29, 2019 at 09:02:34PM +, Ken Moffat wrote: On Sun, Dec 29, 2019 at 01:40:17PM -0600, Bruce Dubbs wrote: On 12/29/19 12:03 PM, Alan Feuerbacher wrote: On 12/29/2019 9:35 AM, Bruce Dubbs wrote: On 12/29/19 9:45 AM, Alan Feuerbacher wrote: What do you get for "ldd /tools/bin/python3" ? -- Bruce (lfs chroot) root:/tools/bin# ldd /tools/bin/python3 linux-vdso.so.1 (0x7ffcc9e82000) libcrypt.so.2 => not found libpthread.so.0 => /tools/lib/libpthread.so.0 (0x7f8eaa69b000) libdl.so.2 => /tools/lib/libdl.so.2 (0x7f8eaa696000) libutil.so.1 => /tools/lib/libutil.so.1 (0x7f8eaa691000) libm.so.6 => /tools/lib/libm.so.6 (0x7f8eaa54e000) libc.so.6 => /tools/lib/libc.so.6 (0x7f8eaa39) /lib64/ld-linux-x86-64.so.2 => /tools/lib64/ld-linux-x86- 64.so.2 (0x7f8eaa6be000) 'libcrypt.so.2 => not found' is enough to prevent the application from running. libcrypt.so.1 should have been installed by glibc. I do not know why python is looking for libcrypt.so.2. Is that from your host? Is Alan building on fedora-30 or later ? A gurgle for libcrypt.so.2 found https://bugzilla.redhat.com/show_bug.cgi?id=1666033 Apparently fedora have moved to libxcrypt. There is a libxcrypt-compat package which installs libcrypt.so.1. Whether installing that on the host will help for LFS I have no idea, but I suspect it won't be that simple. Looking at https://github.com/pypa/manylinux/issues/305 I suspect that this might be problematic. But probably only for python. And the reasoning for the change is at https://fedoraproject.org/wiki/Changes/FullyRemoveDeprecatedAndUnsafeFunctionsFromLibcrypt ĸen Perhaps, before building python in /tools, ln -sv libcrypt.so.1 /tools/libcrypt.so.2 (just a suggestion, I've no way of testing it) I don't see that. Glibc-2.30 in section 5.7 should create libcrypt.so.1 in /tools/lib. -- 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
Re: [lfs-support] Chroot Path Problem for Python
On Sun, Dec 29, 2019 at 09:02:34PM +, Ken Moffat wrote: > On Sun, Dec 29, 2019 at 01:40:17PM -0600, Bruce Dubbs wrote: > > On 12/29/19 12:03 PM, Alan Feuerbacher wrote: > > > On 12/29/2019 9:35 AM, Bruce Dubbs wrote: > > > > On 12/29/19 9:45 AM, Alan Feuerbacher wrote: > > > > > > > > What do you get for "ldd /tools/bin/python3" ? > > > > > > > > -- Bruce > > > > > > (lfs chroot) root:/tools/bin# ldd /tools/bin/python3 > > > linux-vdso.so.1 (0x7ffcc9e82000) > > > libcrypt.so.2 => not found > > > libpthread.so.0 => /tools/lib/libpthread.so.0 > > > (0x7f8eaa69b000) > > > libdl.so.2 => /tools/lib/libdl.so.2 (0x7f8eaa696000) > > > libutil.so.1 => /tools/lib/libutil.so.1 (0x7f8eaa691000) > > > libm.so.6 => /tools/lib/libm.so.6 (0x7f8eaa54e000) > > > libc.so.6 => /tools/lib/libc.so.6 (0x7f8eaa39) > > > /lib64/ld-linux-x86-64.so.2 => /tools/lib64/ld-linux-x86- > > > 64.so.2 (0x7f8eaa6be000) > > > > > > > 'libcrypt.so.2 => not found' is enough to prevent the application from > > running. libcrypt.so.1 should have been installed by glibc. I do not know > > why python is looking for libcrypt.so.2. Is that from your host? > > > > Is Alan building on fedora-30 or later ? > > A gurgle for libcrypt.so.2 found > https://bugzilla.redhat.com/show_bug.cgi?id=1666033 > > Apparently fedora have moved to libxcrypt. There is a > libxcrypt-compat package which installs libcrypt.so.1. > Whether installing that on the host will help for LFS > I have no idea, but I suspect it won't be that simple. > > Looking at https://github.com/pypa/manylinux/issues/305 > I suspect that this might be problematic. But probably > only for python. > > And the reasoning for the change is at > https://fedoraproject.org/wiki/Changes/FullyRemoveDeprecatedAndUnsafeFunctionsFromLibcrypt > > ĸen Perhaps, before building python in /tools, ln -sv libcrypt.so.1 /tools/libcrypt.so.2 (just a suggestion, I've no way of testing it) ĸen -- We've all got both light and dark inside of us. What matters is the part we choose to act on. -- Sirius Black -- 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
Re: [lfs-support] Chroot Path Problem for Python
On Sun, Dec 29, 2019 at 01:40:17PM -0600, Bruce Dubbs wrote: > On 12/29/19 12:03 PM, Alan Feuerbacher wrote: > > On 12/29/2019 9:35 AM, Bruce Dubbs wrote: > > > On 12/29/19 9:45 AM, Alan Feuerbacher wrote: > > > > > > What do you get for "ldd /tools/bin/python3" ? > > > > > > -- Bruce > > > > (lfs chroot) root:/tools/bin# ldd /tools/bin/python3 > > linux-vdso.so.1 (0x7ffcc9e82000) > > libcrypt.so.2 => not found > > libpthread.so.0 => /tools/lib/libpthread.so.0 > > (0x7f8eaa69b000) > > libdl.so.2 => /tools/lib/libdl.so.2 (0x7f8eaa696000) > > libutil.so.1 => /tools/lib/libutil.so.1 (0x7f8eaa691000) > > libm.so.6 => /tools/lib/libm.so.6 (0x7f8eaa54e000) > > libc.so.6 => /tools/lib/libc.so.6 (0x7f8eaa39) > > /lib64/ld-linux-x86-64.so.2 => /tools/lib64/ld-linux-x86- > > 64.so.2 (0x7f8eaa6be000) > > > > 'libcrypt.so.2 => not found' is enough to prevent the application from > running. libcrypt.so.1 should have been installed by glibc. I do not know > why python is looking for libcrypt.so.2. Is that from your host? > Is Alan building on fedora-30 or later ? A gurgle for libcrypt.so.2 found https://bugzilla.redhat.com/show_bug.cgi?id=1666033 Apparently fedora have moved to libxcrypt. There is a libxcrypt-compat package which installs libcrypt.so.1. Whether installing that on the host will help for LFS I have no idea, but I suspect it won't be that simple. Looking at https://github.com/pypa/manylinux/issues/305 I suspect that this might be problematic. But probably only for python. And the reasoning for the change is at https://fedoraproject.org/wiki/Changes/FullyRemoveDeprecatedAndUnsafeFunctionsFromLibcrypt ĸen -- We've all got both light and dark inside of us. What matters is the part we choose to act on. -- Sirius Black -- 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
Re: [lfs-support] Chroot Path Problem for Python
On 12/29/19 12:03 PM, Alan Feuerbacher wrote: On 12/29/2019 9:35 AM, Bruce Dubbs wrote: On 12/29/19 9:45 AM, Alan Feuerbacher wrote: I'm building LFS Version 20191222-systemd, and have run into a problem I've not seen before. I've entered the Chroot Environment section and have gotten up to building glibc. Configure for glibc failed for the Python3 check. For some reason, the chroot environment does not find python3 to check its version, although it finds other programs with no trouble. For example, the system finds sed: ### (lfs chroot) root:/tools/bin# ./sed --version ./sed (GNU sed) 4.7 . . . ### But the system does not find python3.8 or the link python3: ### (lfs chroot) root:/tools/bin# ./python3.8 --version bash: ./python3.8: No such file or directory ### Yet everything looks fine in a directory listing: ### (lfs chroot) root:/tools/bin# ls -l py* lrwxrwxrwx 1 root root 8 Dec 29 06:02 pydoc3 -> pydoc3.8 -rwxr-xr-x 1 root root 80 Dec 29 06:02 pydoc3.8 lrwxrwxrwx 1 root root 9 Dec 29 06:02 python3 -> python3.8 lrwxrwxrwx 1 root root 16 Dec 29 06:02 python3-config -> python3.8-config -rwxr-xr-x 1 root root 20059976 Dec 29 06:02 python3.8 -rwxr-xr-x 1 root root 3083 Dec 29 06:02 python3.8-config ### Am I missing something? What do you get for "ldd /tools/bin/python3" ? -- Bruce (lfs chroot) root:/tools/bin# ldd /tools/bin/python3 linux-vdso.so.1 (0x7ffcc9e82000) libcrypt.so.2 => not found libpthread.so.0 => /tools/lib/libpthread.so.0 (0x7f8eaa69b000) libdl.so.2 => /tools/lib/libdl.so.2 (0x7f8eaa696000) libutil.so.1 => /tools/lib/libutil.so.1 (0x7f8eaa691000) libm.so.6 => /tools/lib/libm.so.6 (0x7f8eaa54e000) libc.so.6 => /tools/lib/libc.so.6 (0x7f8eaa39) /lib64/ld-linux-x86-64.so.2 => /tools/lib64/ld-linux-x86- 64.so.2 (0x7f8eaa6be000) 'libcrypt.so.2 => not found' is enough to prevent the application from running. libcrypt.so.1 should have been installed by glibc. I do not know why python is looking for libcrypt.so.2. Is that from your host? -- 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
Re: [lfs-support] Chroot Path Problem for Python
On 12/29/2019 9:35 AM, Bruce Dubbs wrote: On 12/29/19 9:45 AM, Alan Feuerbacher wrote: I'm building LFS Version 20191222-systemd, and have run into a problem I've not seen before. I've entered the Chroot Environment section and have gotten up to building glibc. Configure for glibc failed for the Python3 check. For some reason, the chroot environment does not find python3 to check its version, although it finds other programs with no trouble. For example, the system finds sed: ### (lfs chroot) root:/tools/bin# ./sed --version ./sed (GNU sed) 4.7 . . . ### But the system does not find python3.8 or the link python3: ### (lfs chroot) root:/tools/bin# ./python3.8 --version bash: ./python3.8: No such file or directory ### Yet everything looks fine in a directory listing: ### (lfs chroot) root:/tools/bin# ls -l py* lrwxrwxrwx 1 root root 8 Dec 29 06:02 pydoc3 -> pydoc3.8 -rwxr-xr-x 1 root root 80 Dec 29 06:02 pydoc3.8 lrwxrwxrwx 1 root root 9 Dec 29 06:02 python3 -> python3.8 lrwxrwxrwx 1 root root 16 Dec 29 06:02 python3-config -> python3.8-config -rwxr-xr-x 1 root root 20059976 Dec 29 06:02 python3.8 -rwxr-xr-x 1 root root 3083 Dec 29 06:02 python3.8-config ### Am I missing something? What do you get for "ldd /tools/bin/python3" ? -- Bruce (lfs chroot) root:/tools/bin# ldd /tools/bin/python3 linux-vdso.so.1 (0x7ffcc9e82000) libcrypt.so.2 => not found libpthread.so.0 => /tools/lib/libpthread.so.0 (0x7f8eaa69b000) libdl.so.2 => /tools/lib/libdl.so.2 (0x7f8eaa696000) libutil.so.1 => /tools/lib/libutil.so.1 (0x7f8eaa691000) libm.so.6 => /tools/lib/libm.so.6 (0x7f8eaa54e000) libc.so.6 => /tools/lib/libc.so.6 (0x7f8eaa39) /lib64/ld-linux-x86-64.so.2 => /tools/lib64/ld-linux-x86- 64.so.2 (0x7f8eaa6be000) -- 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
Re: [lfs-support] Chroot Path Problem for Python
On 12/29/2019 9:31 AM, Xi Ruoyao wrote: On 2019-12-29 08:45 -0700, Alan Feuerbacher wrote: I'm building LFS Version 20191222-systemd, and have run into a problem I've not seen before. I've entered the Chroot Environment section and have gotten up to building glibc. Configure for glibc failed for the Python3 check. For some reason, the chroot environment does not find python3 to check its version, although it finds other programs with no trouble. For example, the system finds sed: ### (lfs chroot) root:/tools/bin# ./sed --version ./sed (GNU sed) 4.7 . . . ### But the system does not find python3.8 or the link python3: ### (lfs chroot) root:/tools/bin# ./python3.8 --version bash: ./python3.8: No such file or directory ### Yet everything looks fine in a directory listing: ### (lfs chroot) root:/tools/bin# ls -l py* lrwxrwxrwx 1 root root8 Dec 29 06:02 pydoc3 -> pydoc3.8 -rwxr-xr-x 1 root root 80 Dec 29 06:02 pydoc3.8 lrwxrwxrwx 1 root root9 Dec 29 06:02 python3 -> python3.8 lrwxrwxrwx 1 root root 16 Dec 29 06:02 python3-config -> python3.8-config -rwxr-xr-x 1 root root 20059976 Dec 29 06:02 python3.8 -rwxr-xr-x 1 root root 3083 Dec 29 06:02 python3.8-config ### Am I missing something? Alan Try: readelf -l /usr/bin/gcc | grep interpreter It should say "[Requesting program interpreter: /tools/lib64/ld-linux-x86- 64.so.2]". On 32-bit systems it may be /tools/lib/ld-linux.so.2. Anyway there should be a /tools prefix. If it's correct, try /tools/bin/ldd /usr/bin/python3.8 If there is any dependency "not found", that's the problem. On UNIX if "execve" call returns with ENOENT, there is no way to figure out if the executable file itself does not exist or one necessary shared object does not exist. So the shell just say "No such file" and the user should investigate to figure out the reason. (I've seen this kind of "the executable exists but shell say no such file" questions many times. Is it in the FAQ? If not we should add it.) I think you meant "/tools/bin/gcc", right? So (lfs chroot) root:/tools/bin# readelf -l /usr/bin/gcc | grep interpreter readelf: Error: '/usr/bin/gcc': No such file (lfs chroot) root:/tools/bin# readelf -l /tools/bin/gcc | grep interpreter [Requesting program interpreter: /tools/lib64/ld-linux-x86-64.so.2] Similarly: (lfs chroot) root:/tools/bin# /tools/bin/ldd /usr/bin/python3.8 ldd: /usr/bin/python3.8: No such file or directory (lfs chroot) root:/tools/bin# /tools/bin/ldd /tools/bin/python3.8 linux-vdso.so.1 (0x7ffe8dde) libcrypt.so.2 => not found libpthread.so.0 => /tools/lib/libpthread.so.0 (0x7fdcf7e8) libdl.so.2 => /tools/lib/libdl.so.2 (0x7fdcf7e7b000) libutil.so.1 => /tools/lib/libutil.so.1 (0x7fdcf7e76000) libm.so.6 => /tools/lib/libm.so.6 (0x7fdcf7d33000) libc.so.6 => /tools/lib/libc.so.6 (0x7fdcf7b75000) /lib64/ld-linux-x86-64.so.2 => /tools/lib64/ld-linux-x86- 64.so.2 (0x7fdcf7ea3000) The only "not found" is libcrypt.so.2 => not found Another check: lfs chroot) root:/tools/bin# ldd --version ldd (GNU libc) 2.30 Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper. -- 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
Re: [lfs-support] Chroot Path Problem for Python
On 12/29/19 9:45 AM, Alan Feuerbacher wrote: I'm building LFS Version 20191222-systemd, and have run into a problem I've not seen before. I've entered the Chroot Environment section and have gotten up to building glibc. Configure for glibc failed for the Python3 check. For some reason, the chroot environment does not find python3 to check its version, although it finds other programs with no trouble. For example, the system finds sed: ### (lfs chroot) root:/tools/bin# ./sed --version ./sed (GNU sed) 4.7 . . . ### But the system does not find python3.8 or the link python3: ### (lfs chroot) root:/tools/bin# ./python3.8 --version bash: ./python3.8: No such file or directory ### Yet everything looks fine in a directory listing: ### (lfs chroot) root:/tools/bin# ls -l py* lrwxrwxrwx 1 root root8 Dec 29 06:02 pydoc3 -> pydoc3.8 -rwxr-xr-x 1 root root 80 Dec 29 06:02 pydoc3.8 lrwxrwxrwx 1 root root9 Dec 29 06:02 python3 -> python3.8 lrwxrwxrwx 1 root root 16 Dec 29 06:02 python3-config -> python3.8-config -rwxr-xr-x 1 root root 20059976 Dec 29 06:02 python3.8 -rwxr-xr-x 1 root root 3083 Dec 29 06:02 python3.8-config ### Am I missing something? What do you get for "ldd /tools/bin/python3" ? -- 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
Re: [lfs-support] Chroot Path Problem for Python
On 2019-12-29 08:45 -0700, Alan Feuerbacher wrote: > I'm building LFS Version 20191222-systemd, and have run into a problem > I've not seen before. I've entered the Chroot Environment section > and have gotten up to building glibc. > > Configure for glibc failed for the Python3 check. For some reason, > the chroot environment does not find python3 to check its version, > although it finds other programs with no trouble. > > For example, the system finds sed: > ### > (lfs chroot) root:/tools/bin# ./sed --version > ./sed (GNU sed) 4.7 > . . . > ### > > But the system does not find python3.8 or the link python3: > ### > (lfs chroot) root:/tools/bin# ./python3.8 --version > bash: ./python3.8: No such file or directory > ### > > Yet everything looks fine in a directory listing: > ### > (lfs chroot) root:/tools/bin# ls -l py* > lrwxrwxrwx 1 root root8 Dec 29 06:02 pydoc3 -> pydoc3.8 > -rwxr-xr-x 1 root root 80 Dec 29 06:02 pydoc3.8 > lrwxrwxrwx 1 root root9 Dec 29 06:02 python3 -> python3.8 > lrwxrwxrwx 1 root root 16 Dec 29 06:02 python3-config -> > python3.8-config > -rwxr-xr-x 1 root root 20059976 Dec 29 06:02 python3.8 > -rwxr-xr-x 1 root root 3083 Dec 29 06:02 python3.8-config > ### > > Am I missing something? > > Alan Try: readelf -l /usr/bin/gcc | grep interpreter It should say "[Requesting program interpreter: /tools/lib64/ld-linux-x86- 64.so.2]". On 32-bit systems it may be /tools/lib/ld-linux.so.2. Anyway there should be a /tools prefix. If it's correct, try /tools/bin/ldd /usr/bin/python3.8 If there is any dependency "not found", that's the problem. On UNIX if "execve" call returns with ENOENT, there is no way to figure out if the executable file itself does not exist or one necessary shared object does not exist. So the shell just say "No such file" and the user should investigate to figure out the reason. (I've seen this kind of "the executable exists but shell say no such file" questions many times. Is it in the FAQ? If not we should add it.) -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- 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
[lfs-support] Chroot Path Problem for Python
I'm building LFS Version 20191222-systemd, and have run into a problem I've not seen before. I've entered the Chroot Environment section and have gotten up to building glibc. Configure for glibc failed for the Python3 check. For some reason, the chroot environment does not find python3 to check its version, although it finds other programs with no trouble. For example, the system finds sed: ### (lfs chroot) root:/tools/bin# ./sed --version ./sed (GNU sed) 4.7 . . . ### But the system does not find python3.8 or the link python3: ### (lfs chroot) root:/tools/bin# ./python3.8 --version bash: ./python3.8: No such file or directory ### Yet everything looks fine in a directory listing: ### (lfs chroot) root:/tools/bin# ls -l py* lrwxrwxrwx 1 root root8 Dec 29 06:02 pydoc3 -> pydoc3.8 -rwxr-xr-x 1 root root 80 Dec 29 06:02 pydoc3.8 lrwxrwxrwx 1 root root9 Dec 29 06:02 python3 -> python3.8 lrwxrwxrwx 1 root root 16 Dec 29 06:02 python3-config -> python3.8-config -rwxr-xr-x 1 root root 20059976 Dec 29 06:02 python3.8 -rwxr-xr-x 1 root root 3083 Dec 29 06:02 python3.8-config ### Am I missing something? Alan -- 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
