On 06/15/2014 06:08 PM, Ken Moffat wrote:
On Sun, Jun 15, 2014 at 04:46:02PM -0500, Dan McGhee wrote:
If it's what I think it is, it's more than an "OOOPS" for me, but I'm trying
to be socially acceptable. This is a little long and involved.
Configure failed on binutils-2.24 with what turned out to be
gcc: error while loading shared libraries: libgcc_s.so.1: cannot open
shared object file: No such file or directory
Now comes the really bad part. 'ls -al /usr/lib | grep libgcc' gives
lrwxrwxrwx 1 root root 22 Oct 20 2013 libgcc_s.so ->
/tools/lib/libgcc_s.so
lrwxrwxrwx 1 root root 24 Oct 20 2013
libgcc_s.so.1 -> /tools/lib/libgcc_s.so.1
It looks like I got bit by my beloved Package Users system. The install
error log showed
*** The file or link: "/usr/lib/../lib64/libgcc_s.so.1" is owned by root
and not gcc-4.8.1
*** The file or link: "/usr/lib/../lib64/libgcc_s.so" is owned by "root"
and not "gcc-4.8.1"
*** The file: "/usr/lib/libgcc_s.so" is owned by "root" and not
"gcc-4.8.1"
A painful lesson, you have my sympathies. As a general rule,
move /tools to a new name before you boot the system (or, after, and
then reboot to check it still boots). When it boots without /tools,
you can remove it and create a symlink to /mnt/lfs/tools ready for
your next build.
Thanks for the kind words. I also look at it as one of those lessons in
humility that I need from time to time. Thanks for the hint about
/tools. I just told a friend of mine that if this had happened before
the end of last December, I could have trashed the whole thing and
started over. But now.....
gcc-4.8.1 is the "user" that built gcc. And it looks like, because the link
could not be removed, the library never got installed and I got bitten
really hard by my Package User System. I darkly remember seeing that
message at the time and didn't do any further checking. I've never had
anything like this happen before.
Sadly, it is weird and unique issues like this which cause me to
suggest that the hint is more trouble than it is worth. I am sure
that some people have no problems with it, and therefore we only see
the people who got bitten by it, but personally I would not touch it
with the proverbial barge pole. So, not "I told you so" but "for
any script, try to understand _how_ it will fail".
Using this hint can be particularly frustrating. And, yes, it can be a
lot of trouble. In this particular case the script didn't fail, I did.
I saw the message. But what frustrates me is that further in Ch 6, I
saw the same message for other packages, fixed the ownership and the
package installed. Just one of those things. But your words about
learning how things can fail is really important--and maybe more
important than knowing how things work--and many times a hard lesson.
After I discovered this and posted to the list, I checked all the other
links set in Ch 6 and for the appropriate ones the only one that slipped
through was this one. Murphy's Law again.
In my own case, I changed my scripts at some point in the last year
or so (to get better logging - anything changed during the package
should get into a "modified" log, including (in BLFS) system files
in e.g. /var which are often irrelevant), and I am *perhaps* now up
to speed with how it fails (in my case, understanding how little
information I get now that I have moved to 'set -e' instead of
testing $? everywhere, and being aware that my top-level scripts,
e.g. for chapter 6 or for everything I build in Xorg, can manage to
continue even after failures _if_ I omit a '&&' on a package script).
For detecting files overwritten by another package, yes, package
users seems to work - my own routines _mainly_ will catch this in my
logs (if I can be bothered to look : it does not get flagged up
strongly and I only really care when we are heading for a new LFS
release). But, I build over 350 packages in a typical desktop BLFS
install. I see no benefit to having that many users on my system.
There is no benefit to all those users. In fact, if, and now that "if"
is much larger than before, a package gets installed successfully,
there's no reason to keep the user around. I've never deleted any, but
still I don't need 'em.
I've experimented with my Recovery Option One and created $LFS/toolz.
Binutils compiled fine. I chose that name in my cynical, sarcastic mode
and think I will change it again to something a little less prone to
typing errors. Copying and Pasting now will not be as routine, but, I
did it and now experiencing the consequences.
I'm still amazed at what I lost in my desktop environment. I guess
those two gcc libraries are important even when not compiling.
Thanks, Ken.
Dan
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
