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. > 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". 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. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
