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 :
http://archive.linuxfromscratch.org/mail-archives/lfs-support/2013-October/045681.html
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
> SHLVL=1
> 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.
http://trac.clfs.org/wiki/lists
ĸen
--
`I shall take my mountains', said Lu-Tze. `The climate will be good
for them.' -- Small Gods
--
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
