On 1/5/2020 9:05 AM, Xi Ruoyao wrote:
On 2020-01-04 18:13 -0700, Alan Feuerbacher wrote:
On 1/4/2020 12:49 PM, Xi Ruoyao wrote:
On 2020-01-04 10:21 -0700，Alan Feuerbacher wrote:
I've run into a problem in building Version 20200101-systemd Section
6.9. Glibc-2.30.
After several repetitions of compiling, I've found that if I run
"make check", the various localedef invocations that follow, like
"localedef -i cs_CZ -f UTF-8 cs_CZ.UTF-8", sometimes fail with a message
like
"cannot create temporary file: /tools/lib/locale/locale-archive.J6uC5g:
No such file or directory".
However, if I skip "make check", all of the "localedef" commands
run ok.
That's abnormal. NEVER continue blindly with this kind of phenomena. That
may
be a bomb and may blow up your entire system.
Can you please expand on what I did wrong? I don't really understand
what you mean by "continue blindly".
I'm not blaming you. lfs-support is a maillist so I should assert this for
everyone who may search the maillist archive when he/she meets the same problem.
In an abnormal situation, if we can find a way to fix it, let's go and fix it.
But if not, the only correct thing to do is to restart the entire LFS build.
Some people may think "whoa, the next package can be built successfully" and
continue, trying to save some time. Then they actually cost more time - at last
they find out the system is totally broken, in maybe Chap. 7 or 8.
Yes, I've learned that the hard way. Problem is, I don't yet have enough
experience to know if I have a truly abnormal situation, or just a
situation due to mistyping or forgetting to execute a command.
So now I'm less averse to starting from scratch, even though it's painful.
After some investigation I found the following:
The behavior is partly repeatable, in the sense that in doing about
half a dozen builds, sometimes the problem appeared and sometimes not.
I could see no pattern to the failures and successes. The final time
I ran "make check", all of the "localedef ..." commands succeeded.
So I've proceeded with the rest of Section 6 to nearly the end.
Before doing all builds again, I wiped the hard drive and started
from scratch, installing everything in the LFS book up through
Section 6.9.
A few details:
After all the runs of "make check", whether "localedef ..." succeeded
or not, /tools/lib exists but /tools/lib/locale does not exist. So
the question is: why is "localedef" sometimes looking for a
non-existent directory?
Glibc configuration script sets up a variable named "libc_cv_complocaledir".
It's value is defaulted to be $libdir/locale. It's then hard-coded into
localedef binary and libc libraries. So /tools/bin/localedef will always
look
for /tools/lib/locale.
But I thought that configuring with --prefix=/usr forces files to be put
in /usr/lib and /usr/bin . So I would think that you would get a default
of /usr/lib/locale. I checked, and there does exist
/usr/lib/locale/locale-archive, which I'm sure is correct.
/usr/bin/localedef will look for /usr/lib/locale (if it is configured
correctly), but /tools/bin/localedef will still look for /tools/lib/locale. If
your shell picks /tools/bin/localedef, instead of newly built
/usr/bin/localedef, it would be a problem.
I suspect that I mistyped something in my script, which then did not
fully execute, which then produced the problem. See below for an example.
My guess: either you forgot to run "make install" after "make check" (I
really
have done this stupid thing several times), or you forgot to use "+h" in
section
6.4. Without "+h" bash may remember /tools/bin/localedef and use it even if
/usr/bin/localedef is newly installed.
Another possibility: you forgot to remove glibc-2.30 directory after building
it in Chap. 5. Then the Chap. 6 build picked up some old object files
containing "/tools/lib/locale".
Entirely possible.
I've wrapped the various commands in a sort of script, so that I can
more easily run them reliably, since running each command individually
from the LFS book is extremely prone to errors of omission for me. I
think I screwed up some of the syntax.
I started over again with glibc after cleaning up my script. No issues
now. Thanks!
I manually inputed all instructions during my first LFS build, to make sure I
understand what this instruction is doing. For later builds I just copy-n-paste
(and maybe modify it a little, if necessary).
That's essentially what I've been doing. Of course, mistakes creep in.
For scripting, I think something like "&&" or "bash -e" should be used. Then
the script will fail if something goes wrong, instead of continuing to run the
next command (really blindly, since shell interpreter has no brains or eyes :).
Here is a typical script that I've used to record compile times:
tar xf libunistring-0.9.10.tar.xz &&
cd libunistring-0.9.10 &&
time { \
./configure --prefix=/usr \
--disable-static \
--docdir=/usr/share/doc/libunistring-0.9.10 &&
make \
; }
echo "Exit status" $?
###########
real 1m8.122s
user 0m51.183s
sys 0m14.527s
###########
time { \
make check \
; }
echo "Exit status" $?
###########
real 1m19.729s
user 1m1.254s
sys 0m21.167s
###########
make install &&
cd .. &&
rm -rf libunistring-0.9.10
Each time I went through it, I highlighted from "tar ..." through "echo ...", pasted it into the terminal I use for execution,
and let her rip. Then I pasted the "time" results back into the script. Then I did the same for the "time ..." through "echo
..." lines. Finally I executed the "make ..." through "rm ..." lines. Normally this all works well.
Is this script ok by you? Any suggestions for improvement?
After looking over my scripts more carefully, I found a mistake: in some
scripts I had lines something like this:
make \
# This is a comment
; }
echo "Exit status" $?
According to what I understood of bash, any line beginning with '#' is ignored.
But that's not actually the case: bash complains of a syntax error and quits. I
might have missed this a few times. So I've learned that you must put comment
lines *outside* of continuation lines (ones that end with \ ).
So a cleaned up script, that could be executed all in one go, would be:
tar xf libunistring-0.9.10.tar.xz &&
cd libunistring-0.9.10 &&
time { \
./configure --prefix=/usr \
--disable-static \
--docdir=/usr/share/doc/libunistring-0.9.10 &&
make \
; } &&
echo "Exit status" $? &&
###########
# real 1m8.122s
# user 0m51.183s
# sys 0m14.527s
###########
time { \
make check \
; } &&
echo "Exit status" $? &&
###########
# real 1m19.729s
# user 1m1.254s
# sys 0m21.167s
###########
make install &&
cd .. &&
rm -rf libunistring-0.9.10
Comments?
Lastly, in order to create one log file, I think I should be able to wrap the
script in a subshell, like so:
( ( tar ... &&
. . .
rm ... ) 2>&1 | tee libunistring.log && exit $PIPESTATUS ) &&
echo "Exit status" $?
That works, but is there a better way? Should I use bash -e in some variation?
Alan
--
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
