Re: [lfs-support] Building Python3
On Tue, Feb 09, 2021 at 03:24:53PM -0500, Baho Utot wrote: > A note should be placed in the book about --with-ensurepip=yes. > > It will not build pip, setuptools and wheel if they are already installed on > the system. > > Rebuilding python3 will not rebuild pip, setuptools and wheel as it detects > that they are already installed on the system. > > Even if they are older than the package currently being built. > > ./configure --prefix=/usr \ > --enable-shared \ > --with-system-expat \ > --with-system-ffi \ > --with-ensurepip=yes > Hi Scott, did you mean to post this to blfs-support rather than lfs-support ? In LFS the first build has --without-ensurepip so the second build should install it, and both will be for the same version. I don't think I have a system upgraded from 3.9 to 3.9.1 (been too busy working on systems with 3.9.1), but on the current system (3.9.1 in LFS, rebuilt in BLFS) in LFS it installed /usr/lib/python3.9/site-packages/setuptools /usr/lib/python3.9/site-packages/setuptools-49.2.1.* with /usr/lib/python3.9/site-packages/setuptools/__init__.py and various /usr/lib/python3.9/site-packages/setuptools/__pycache__/*.pyc and various other files in /usr/lib/python3.9/site-packages/setuptools/ and its subdirectories. When I rebuilt it in BLFS it seems to have overwritten one or two of those files and added a load more. and the same for pip although the only identifier for pip i nthe rebuild seems to be cpython-39 whereas in LFS chapter 8 I see pip-20.2.3.dist-info. I'm willing to believe that upgrading minor versions of python might not upgrade pip and setuptools. But I'm not a pythonista, so I have to ask: does it matter ? If you do need to upgrade it (latest is now apparently v21.0.1, which dropped support for python2), according to https://pip.pypa.io/en/stable/installing/#upgrading-pip you can run python -m pip install -U pip (assuming you have python symlinked to python3, which will break seamonkey and qtwebengine out of packages in BLFS). Since you use a package manager, doing that as a regular user will install in ~/.local/bin but all it actually does is install pip, pip3, pip3.9. I conclude that setuptools will NOT be upgraded, and I will be surprised if pip, pip3 or pip3.9 ever change. ĸen -- Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout. -- rfc 2324 (1st April 1998) -- 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] Compile error glibc2.33 -> binutils-2.36.1
On Tue, Feb 09, 2021 at 05:14:09PM -0500, Jean-Marc Pigeon wrote: > Hello, > On Tue, 2021-02-09 at 18:27 +, Ken Moffat wrote: > > On Tue, Feb 09, 2021 at 12:29:14AM +, Ken Moffat wrote: > > > On Mon, Feb 08, 2021 at 03:52:35AM +, Ken Moffat wrote: > > > > > > > > ../configure --prefix=/usr \ > > > > --disable-werror \ > > > > --enable-kernel=3.2 \ > > > > --enable-stack-protector=strong \ > > > > --with-headers=/usr/include \ > > > > libc_cv_slibdir=/lib > > > > libc_cv_include_x86_isa_level=no > > > > [...] > > > Well I don't need that workaround for using '-march=native -O2' on > > > my skylake, it booted successfully. Fortunately, Frans said it > > > works for him, and htat distros are using it, so I guess we too > > > should use it. > > > > > > However, there was one problem other than my own typos in editing > > > scripts - tried to build linux-5.10.13 - > > > > > > CC arch/x86/kernel/apic/apic.o > > > make[3]: *** [scripts/Makefile.build:279: > > > arch/x86/kernel/apic/apic.o] Segmentation fault > Exact same problem here (not a memory problem, or very big > "cosmic ray"). same problem on kernel-5.10.9 too. > this happen using glibc-2.33 AND binutils-2.36.1 > > rebuilding from scratch using binutils-2.36.1 and keeping > glibc-2.32 make the segmentation fault (I previously restarted > build from scratch with glibc-2.32 + binutils-2.35.1, kernel > compilation was OK). > My conclusion, binutils is the trouble maker. > Could somebody confirm this finding? > Google is mute on this subject but may be my search > keywords were not that good. > advices? suggestions? > Wow! I hadn't thought of trying binutils-2.36.1 with glibc-2.32 (partly because I'd prefer to use glibc-2.33 because of its iconv fixes). And I'm surprised at 5.10.9 because based on the kernel list and binutils-bugs I had thought that would crap out in objcopy (with an error message about the sections, not a segfault). This does sound as if it is a real problem, but I guess the reason google is not coming up with anything is that binutils-2.36 and 2.36.1 are fresh. Normally we try to keep on the cutting edge rather than the bleeding edge, but this time we've maybe overshot. Just to be clear (before Bruce asks, I know he distrusts using any CFLAGS) - are you building with any variant of -march= ? And what CPU are you building on ? I'm still not ready to start my next build, but suddenly I'm even less looking forward to it :) If this is a common problem, I would have though Bruce would have seen it when he updated to 2.36 and 2.36.1 - so I assume there is some other factor which is not yet obvious. ĸen -- Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout. -- rfc 2324 (1st April 1998) -- 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] Compile error glibc2.33
On Tue, Feb 09, 2021 at 12:29:14AM +, Ken Moffat wrote: > On Mon, Feb 08, 2021 at 03:52:35AM +, Ken Moffat wrote: > > > > ../configure --prefix=/usr\ > > --disable-werror \ > > --enable-kernel=3.2 \ > > --enable-stack-protector=strong \ > > --with-headers=/usr/include \ > > libc_cv_slibdir=/lib libc_cv_include_x86_isa_level=no > > > > I've started the native build, but the machine is slow (i3, slow > > DRAM) and I'm not sure it will get very far before I go to bed. My > > revised plan is to wait for it to fail, whether that is failign the > > build or failing to boot. > > > > Assuming it does fail, I'll start again with that workaround. > > > Well I don't need that workaround for using '-march=native -O2' on > my skylake, it booted successfully. Fortunately, Frans said it > works for him, and htat distros are using it, so I guess we too > should use it. > > However, there was one problem other than my own typos in editing > scripts - tried to build linux-5.10.13 - > > CC arch/x86/kernel/apic/apic.o > make[3]: *** [scripts/Makefile.build:279: arch/x86/kernel/apic/apic.o] > Segmentation fault > > Feb 8 20:45:13 leshp klogd: [62379.838193] objtool[10870]: segfault at 70 ip > 0040c13e sp 7ffd0f655670 error 4 in objtool[402000+11000] > followed by a dump of the code bytes. > > Decided to try 5.10.14 just in case, but that failed the same way, > on the same file (freshly extracted 5.10 source, freshly patched to > .14). Then I tried 5.11.0-rc7 and that built without problems. > > My initial guess is that the memory has gone faulty, so I booted > memtest86. That is currently part-way through the second of four > passes, no errors found so far. Maybe it was the old "cosmic rays" > problem, maybe an error will show before memtest86 finishes, or > maybe binutils-2.36.1 still has a problem with something in the > kernel. > > I suppose I'd better go back to updating the rest of my scripts so > that I can try builds on haswell and zen1 with -march=native.+ > Left memtest86 running, all tests ok, but then I noticed it had only used one core (the default). Went back to the CPU options, but both parrallel (all cores) and round robin quickly reported that UEFI had failed to start CPU2. My LFS systems on hat machine use the bios, I suspect the UEFI problem is par for the course on lower-end machines from that date. I then booted the new svn system again (5.11.0-rc7) and tried to build 5.10.13, 5.10.12, 5.10.15-rc1 : all again failed with a segfault. I'll give it another try with the extra libc_cv setting just in case, but probably not for a few days. First, I'm running memtest86 on my oldest ryzen before trying to build that with -march=native -O3 (again, without the additional libc_cv). ĸen -- Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout. -- rfc 2324 (1st April 1998) -- 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] Compile error glibc2.33 -> binutils-2.36.1
Hello, On Tue, 2021-02-09 at 18:27 +, Ken Moffat wrote: > On Tue, Feb 09, 2021 at 12:29:14AM +, Ken Moffat wrote: > > On Mon, Feb 08, 2021 at 03:52:35AM +, Ken Moffat wrote: > > > > > > ../configure --prefix=/usr \ > > > --disable-werror \ > > > --enable-kernel=3.2 \ > > > --enable-stack-protector=strong \ > > > --with-headers=/usr/include \ > > > libc_cv_slibdir=/lib > > > libc_cv_include_x86_isa_level=no > > > > > > I've started the native build, but the machine is slow (i3, slow > > > DRAM) and I'm not sure it will get very far before I go to bed. > > > My > > > revised plan is to wait for it to fail, whether that is failign > > > the > > > build or failing to boot. > > > > > > Assuming it does fail, I'll start again with that workaround. > > > > > Well I don't need that workaround for using '-march=native -O2' on > > my skylake, it booted successfully. Fortunately, Frans said it > > works for him, and htat distros are using it, so I guess we too > > should use it. > > > > However, there was one problem other than my own typos in editing > > scripts - tried to build linux-5.10.13 - > > > > CC arch/x86/kernel/apic/apic.o > > make[3]: *** [scripts/Makefile.build:279: > > arch/x86/kernel/apic/apic.o] Segmentation fault Exact same problem here (not a memory problem, or very big "cosmic ray"). same problem on kernel-5.10.9 too. this happen using glibc-2.33 AND binutils-2.36.1 rebuilding from scratch using binutils-2.36.1 and keeping glibc-2.32 make the segmentation fault (I previously restarted build from scratch with glibc-2.32 + binutils-2.35.1, kernel compilation was OK). My conclusion, binutils is the trouble maker. Could somebody confirm this finding? Google is mute on this subject but may be my search keywords were not that good. advices? suggestions? > > > > Feb 8 20:45:13 leshp klogd: [62379.838193] objtool[10870]: > > segfault at 70 ip 0040c13e sp 7ffd0f655670 error 4 in > > objtool[402000+11000] > > followed by a dump of the code bytes. > > > > Decided to try 5.10.14 just in case, but that failed the same way, > > on the same file (freshly extracted 5.10 source, freshly patched to > > .14). Then I tried 5.11.0-rc7 and that built without problems. > > > > My initial guess is that the memory has gone faulty, so I booted > > memtest86. That is currently part-way through the second of four > > passes, no errors found so far. Maybe it was the old "cosmic rays" > > problem, maybe an error will show before memtest86 finishes, or > > maybe binutils-2.36.1 still has a problem with something in the > > kernel. > > > > I suppose I'd better go back to updating the rest of my scripts so > > that I can try builds on haswell and zen1 with -march=native.+ > > > > Left memtest86 running, all tests ok, but then I noticed it had only > used one core (the default). Went back to the CPU options, but both > parrallel (all cores) and round robin quickly reported that UEFI had > failed to start CPU2. My LFS systems on hat machine use the bios, I > suspect the UEFI problem is par for the course on lower-end > machines from that date. > > I then booted the new svn system again (5.11.0-rc7) and tried to > build 5.10.13, 5.10.12, 5.10.15-rc1 : all again failed with a > segfault. I'll give it another try with the extra libc_cv setting > just in case, but probably not for a few days. > > First, I'm running memtest86 on my oldest ryzen before trying to > build that with -march=native -O3 (again, without the additional > libc_cv). > > ĸen > -- > Any attempt to brew coffee with a teapot should result in the error > code "418 I'm a teapot". The resulting entity body MAY be short and > stout. -- rfc 2324 (1st April 1998) > -- You have seen "Linux from scratch" and looking for ISO files www.osukiss.org -- 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] Building Python3
A note should be placed in the book about --with-ensurepip=yes. It will not build pip, setuptools and wheel if they are already installed on the system. Rebuilding python3 will not rebuild pip, setuptools and wheel as it detects that they are already installed on the system. Even if they are older than the package currently being built. ./configure --prefix=/usr \ --enable-shared \ --with-system-expat \ --with-system-ffi \ --with-ensurepip=yes -- 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] Compiling M4 on GCC 10.2
On 2021-02-09 16:11 +0100, Viktor Engelmann wrote:
> Hello everyone,
>
> I'm building LFS 10.0 on a fully updated Manjaro Linux on an x86_64 for
> x86_64.
>
> When I compile M4 (chapter 6.2), I get two errors:
>
> - gcc complains about a void function ("fault_handler") being declared
> as "pure" in line 146 of m4.c
> - gcc complains about the flag -Wabi which is deprecated and doesn't do
> anything
>
> (see the attached log file)
>
> I was able to circumvent the problems by setting the environment variable
> CFLAGS=" -fpermissive -Wabi=11 " before ./configure, but I think that
> these are infact bugs
> in M4, so gcc is rightfully complaining.
>
> It seems that an older gcc version had failed if that function was NOT
> declared "pure"
> and the M4 team has also discussed this topic in july 2020, see
> https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=fault_handler=Search%21=bug-m4=20=normal=score
> they had also decided to make the function NOT "pure" (because
> fault_handler has sideeffects
> and should therefore not be pure). This was implemented by commit
> 74915227e245c2f93d0db1ff3c53544d8f594dfa in the m4 git repository, but
> the declaration
> is still present in the .tar.xz from 2016 on http://ftp.gnu.org/gnu/m4/
> that is used in LFS.
>
> I verified that LFS and LFS_TGT are set and that I'm compiling with
> x86_64-lfs-linux-gnu-gcc.
> Everything before M4 was built as regular user.
Those warnings should not be enabled by default.
Is your M4 tarball has the same MD5 checksum in the book? Or did you use some
configure options not mentioned by the book?
--
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] Compiling M4 on GCC 10.2
Hello everyone,
I'm building LFS 10.0 on a fully updated Manjaro Linux on an x86_64 for
x86_64.
When I compile M4 (chapter 6.2), I get two errors:
- gcc complains about a void function ("fault_handler") being declared
as "pure" in line 146 of m4.c
- gcc complains about the flag -Wabi which is deprecated and doesn't do
anything
(see the attached log file)
I was able to circumvent the problems by setting the environment variable
CFLAGS=" -fpermissive -Wabi=11 " before ./configure, but I think that
these are infact bugs
in M4, so gcc is rightfully complaining.
It seems that an older gcc version had failed if that function was NOT
declared "pure"
and the M4 team has also discussed this topic in july 2020, see
https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=fault_handler=Search%21=bug-m4=20=normal=score
they had also decided to make the function NOT "pure" (because
fault_handler has sideeffects
and should therefore not be pure). This was implemented by commit
74915227e245c2f93d0db1ff3c53544d8f594dfa in the m4 git repository, but
the declaration
is still present in the .tar.xz from 2016 on http://ftp.gnu.org/gnu/m4/
that is used in LFS.
I verified that LFS and LFS_TGT are set and that I'm compiling with
x86_64-lfs-linux-gnu-gcc.
Everything before M4 was built as regular user.
Kind regards
Viktor
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for x86_64-lfs-linux-gnu-strip... x86_64-lfs-linux-gnu-strip
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking for x86_64-lfs-linux-gnu-gcc... x86_64-lfs-linux-gnu-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether x86_64-lfs-linux-gnu-gcc accepts -g... yes
checking for x86_64-lfs-linux-gnu-gcc option to accept ISO C89... none needed
checking whether x86_64-lfs-linux-gnu-gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of x86_64-lfs-linux-gnu-gcc... gcc3
checking how to run the C preprocessor... x86_64-lfs-linux-gnu-gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether _XOPEN_SOURCE should be defined... no
checking for Minix Amsterdam compiler... no
checking for x86_64-lfs-linux-gnu-ar... x86_64-lfs-linux-gnu-ar
checking the archiver (x86_64-lfs-linux-gnu-ar) interface... ar
checking for x86_64-lfs-linux-gnu-ar... (cached) x86_64-lfs-linux-gnu-ar
checking for x86_64-lfs-linux-gnu-ranlib... x86_64-lfs-linux-gnu-ranlib
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-lfs-linux-gnu
checking for _LARGEFILE_SOURCE value needed for large files... no
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking for x86_64-lfs-linux-gnu-gcc option to accept ISO C99... none needed
checking for x86_64-lfs-linux-gnu-gcc option to accept ISO Standard C...
(cached) none needed
configure: autobuild project... GNU M4
configure: autobuild revision... 1.4.18
configure: autobuild hostname... laptop
configure: autobuild timestamp... 20210209T112704Z
checking whether C compiler handles -Werror -Wunknown-warning-option... no
checking whether C compiler handles -Werror... yes
checking whether pragma GCC diagnostic push works... yes
checking whether pragma GCC diagnostic push works... (cached) yes
checking whether -Wno-missing-field-initializers is supported... yes
checking whether -Wno-missing-field-initializers is needed... no
checking whether -Wuninitialized is supported... yes
checking whether C compiler handles -fno-common... yes
checking whether C compiler handles -W... yes
checking whether C compiler handles -Wabi... yes
checking whether C compiler handles -Waddress... yes
checking whether C compiler handles -Waggressive-loop-optimizations... yes
checking whether C compiler handles -Wall... yes
checking whether C compiler handles -Wattributes... yes
checking whether C compiler handles -Wbad-function-cast... yes
