[lfs-support] file-5.28 make all-recursive error

Ken Moffat zarniwhoop at ntlworld.com
Wed Jan 4 14:49:53 PST 2017

On Wed, Jan 04, 2017 at 06:56:32PM +0000, Roger Frost wrote:
> Greetings,
> I'm at LFS version 7.10, section 6.12. File-5.28
> In short, here is my problem:
> package file:/usr/src/file/file-5.28> make
> make  all-recursive
> make[1]: Entering directory '/usr/src/file/file-5.28'
> Making all in src
> make[1]: *** [Makefile:399: all-recursive] Error 1
> make[1]: Leaving directory '/usr/src/file/file-5.28'
> make: *** [Makefile:331: all] Error 2
> Deviations from the book:
> 1) I'm building a multilib LFS 7.10 system based (loosely) on CLFS Version 3.0.0-SYSVINIT-x86_64-Multilib.
> 2) I employ the Package Users method of package management.
> (Yeah, I know... are you still with me?)
Not really, but I'll see what I can suggest ;-)

When people use Package Users and have problems, I think the main
problem is always perms.  I had a feeling that the hint
("more_control...") was updated in the past few years, but maybe
whoever was trying to do that gave up.  Google found a thread from
October 2013, which I guess was before your 7.7 build :


My other comment on that approach is that I think things have had
to be changed for newer versions of the book.

> Host system:
> Second generation multilib (B)LFS 7.7, also based on CLFS, also with Package Users.
> Package configurations attempted (all produce the same result):
> 1) CC="gcc ${BUILD32}" ./configure --prefix=/usr (<=== this is the one I need to work)
> 2) CC="gcc ${BUILD64}" ./configure --prefix=/usr --libdir=/usr/lib64
> 3) ./configure --prefix=/usr
> 4) ./configure
> 5) ./configure --prefix=/usr --disable-zlib
> Environment:
> package file:/usr/src/file/file-5.28> env
> HZ=100
> CLFS_TARGET32=i686-pc-linux-gnu
> SHELL=/bin/bash
> TERM=xterm
> OLDPWD=/usr/src/file
> USER=file
> BUILD64=-m64
> BUILD32=-m32
> MAIL=/var/spool/mail/file
> PATH=/usr/lib/pkgusr:/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin
> PWD=/usr/src/file/file-5.28
> HOME=/usr/src/file
> LOGNAME=file
> PROMPT_COMMAND=PS1="package \u:"`pwd`"> "
> _=/tools/bin/env
> Other observations:
> 1) The error only happens at the top-level Makefile, (ie. I can './configure && cd src && make' successfully).
> 2) file-5.28 will build on my host system with no deviations from CLFS instructions.
> 3) Attempting to build as root instead of the Package User will fail in exactly the same way.

OK, so probably not perms.

> 4) Attempting to build the old version from LFS 7.7 (file-5.22) in the chroot environment will fail in exactly the same way.
> 5) zlib (32-bit and 64-bit) built without a hitch after the toolchain was adjusted.
> 6) I'm not a Makefile debugger, I don't even play one on TV.
> Bottom Line:
> What could cause a top-level Makefile to fail in this way, yet still be able to 'make' in SUBDIRs?

Try make -d (see 'info make') - that should give you a lot more debug
info than you want, but hopefully something there will point to the
problem.  But see below re sed.
> Could I work around this? Probably, based on the fact that I can 'make' inside the src sub-directory. Do I want to? No, I need to figure out the cause, it's likely to be an ongoing problem if I don't.

I think many people think the hint is the ongoing problem, but I'm
probably biased.

> If you have any questions, please ask! I've tried everything I can think of. I tried to include config.log, but evidently the message was too large (>100KB) and was rejected. I'll be happy to provide any output requested that may help track down the issue.

At this point I decided to look at my own logs - the first thing
make ran was a sed command to create magic.h from magic.h.in.

Your output doesn't show that, which makes me think that perhaps
configure didn't complete successfully.

> And finally, sorry if this is not the best list for this question, but the cross-lfs list appears to have died 5 years ago.

They moved after somebody grabbed their domain.

`I shall take my mountains', said Lu-Tze. `The climate will be good
for them.'     -- Small Gods

More information about the lfs-support mailing list