On Sat, Nov 09, 2019 at 02:25:49PM -0700, Flareon Zulu wrote: > On Sat, 9 Nov 2019, Ken Moffat wrote: > > > On Sat, Nov 09, 2019 at 11:34:42AM -0700, Flareon Zulu wrote: > > > When attempting to build coreutils-8.31 in the chroot envirionment, the > > > build will stop at compiling "expand" with the following log: > > > > > > CC src/expand.o > > > CC src/expand-common.o > > > CCLD src/expand > > > /usr/bin/ld: src/expand.o: in function `expand': > > > expand.c:(.text+0x422): undefined reference to `mbfile_multi_getc' > > > collect2: error: ld returned 1 exit status > > > make[2]: *** [Makefile:8824: src/expand] Error 1 > > > make[2]: Leaving directory '/sources/coreutils-8.31' > > > make[1]: *** [Makefile:12651: all-recursive] Error 1 > > > make[1]: Leaving directory '/sources/coreutils-8.31' > > > make: *** [Makefile:6831: all] Error 2 > > > > > > After attempting the build without the patch, and having it work, I can > > > safely say there is some problem in the patch file. Unfortunately, I'm not > > > good enough in C/C++ to determine what that problem is. > > > > > > Flareon > > > > Very odd. It worked for me, and looking at the patch: > > > > expand.c is modified at patch line 905 onwards, the first change is > > to include mbfile.h. > > > > mbfile.h is added by lines 64 onwards in the patch, and within that > > is the definition of mbfile_multi_getc. > > > > Are you doing something different ? Google finds a similar problem > > two years ago (coreutils-8.28), AFAICS we never got anywhere in > > working out why it was failing. There is also a fedora bug, > > https://bugzilla.redhat.com/show_bug.cgi?id=1688761 where the > > problem showed up using -Os (IMHO that is never a good idea unless > > the package forces it, -Os has been known to create very poor code > > for the kernel and is generally much less well tested). > > > > There was also a similar report in September for Musl-LFS (I didn't > > know that existed!) - https://github.com/dslm4515/Musl-LFS/issues/11 > > which was apparently re building musl LFS on a glibc host, and there > > the solution was to drop the patch because musl doesn't support > > locales! > > > > Alternatively, maybe there is something else different about your > > _host_ system ? > > [...] > My host system is a freshly-installed Ubuntu 19.10 system, with needed tools > installed, mawk replaced with gawk, and nothing I'm aware of being different > in how I went through the rest of the book beforehand. >
Fresh ubuntu ought to be recent enough not to cause difficulties after replacing mawk, but the long-time problem with debian-derived distros has been the /bin/sh symlink. I assume you fixed that to point to/bin/bash, but ISTR problems happened much earlier if that was not fixed. > The only thing that I can think of is that there's a chance the header isn't > being generated correctly by autoconf after patching, but that package was > installed exactly to the book, with no problems. > > Flareon Just on the off-chance, here is my build log from running autorconf in coreutils after applying the patch (although AFAICS the header should just get installed, and the patch should mean that expect.c references it - we know that expand.c _is_ referencing the code). autoreconf: Entering directory `.' autoreconf: running: autopoint --force Copying file build-aux/config.rpath Copying file m4/extern-inline.m4 Copying file m4/glibc2.m4 Copying file m4/intdiv0.m4 Copying file m4/intl.m4 Copying file m4/intldir.m4 Copying file m4/intmax.m4 Copying file m4/printf-posix.m4 Copying file m4/uintmax_t.m4 Copying file m4/visibility.m4 Copying file po/Makefile.in.in Copying file po/Makevars.template autoreconf: running: aclocal --force -I m4 autoreconf: configure.ac: tracing autoreconf: configure.ac: not using Libtool autoreconf: running: /usr/bin/autoconf --force autoreconf: running: /usr/bin/autoheader --force autoreconf: running: automake --add-missing --copy --force-missing gnulib-tests/gnulib.mk:1298: warning: variable 'test_once1_SOURCES' is defined but no program or gnulib-tests/gnulib.mk:1298: library has 'test_once1' as canonical name (possible typo) gnulib-tests/Makefile.am:1: 'gnulib-tests/gnulib.mk' included from here gnulib-tests/gnulib.mk:1300: warning: variable 'test_once2_SOURCES' is defined but no program or gnulib-tests/gnulib.mk:1300: library has 'test_once2' as canonical name (possible typo) gnulib-tests/Makefile.am:1: 'gnulib-tests/gnulib.mk' included from here gnulib-tests/gnulib.mk:1299: warning: variable 'test_once1_LDADD' is defined but no program or gnulib-tests/gnulib.mk:1299: library has 'test_once1' as canonical name (possible typo) gnulib-tests/Makefile.am:1: 'gnulib-tests/gnulib.mk' included from here gnulib-tests/gnulib.mk:1301: warning: variable 'test_once2_LDADD' is defined but no program or gnulib-tests/gnulib.mk:1301: library has 'test_once2' as canonical name (possible typo) gnulib-tests/Makefile.am:1: 'gnulib-tests/gnulib.mk' included from here gnulib-tests/gnulib.mk:1296: warning: variable 'test_rwlock1_LDADD' is defined but no program or gnulib-tests/gnulib.mk:1296: library has 'test_rwlock1' as canonical name (possible typo) gnulib-tests/Makefile.am:1: 'gnulib-tests/gnulib.mk' included from here autoreconf: Leaving directory `.' I'm assuming this is x86_64 (probably called amd64 in ubuntu) ? At the moment I don't have any idea what is going wrong. I don't have a part-built system available, but I assume that src/expand.o got compiled before the error ? Hmm, is this 'make -jN' ? Sometimes odd things fail on some machines, although I've built coreutils using -j8 on a couple of my machines. If you are using a parrallel make, try make -j1 for this, just in case. From my own log, and using 'make V=1' to see the (excessive) detail of the build I can see that _my_ CFLAGS were picked up by configure and expand got compiled: depbase=`echo src/expand.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ gcc -I. -I./lib -Ilib -I./lib -Isrc -I./src -O3 -march=native -D_FORTIFY_SOURCE=2 -fstack-protector-strong -MT src/expand.o -MD -MP -MF $depbase.Tpo -c -o src/expand.o src/expand.c &&\ mv -f $depbase.Tpo $depbase.Po and later it got linked into libcoreutils.a: gcc -O3 -march=native -D_FORTIFY_SOURCE=2 -fstack-protector-strong -Wl,--as-needed -o src/expand src/expand.o src/expand-common.o src/libver.a lib/libcoreutils.a lib/libcoreutils.a And no, I'm not recommending that you use CFLAGS like that (the -Wl,--as-needed should be standard) for a first build, there is a link from the early part of BLFS after you have a working build if anyone wants to look at optimizing or other tuning. But what I cannot find is any mention of mbfile in _my_ log. Very strange. Will have to think about this. ĸen -- Whilst all mushrooms are edible, the trick is to eat only those which will prove to be edible more than once. The Celebrated Discworld Almanak recommends you play safe and eat beans on toast. -- 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
