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
