I'd like to offer a very strong (but polite) dissenting voice about the
subject of NO-NO updating/upgrading "in place" which came up here once again.
1. I started my LFS/BLFS system in 2005 based on whatever instructions
were current at the time.
I upgraded LFS/BLFS software, kernels, what have you, _in place_ literally
thousands of times (I keep records:) without ever running into problems that
could be traced to the "in place" approach.
AAMOF, I've never used (or known of) a way to do things "out of place".
Nor have I ever performed any unusual acrobatics in order to achieve such
an unblemished in-place "record".
Just "configure,make,make install", so to speak.
IRONICALLY, the one and only problem that could possibly be ascribed to
working "in place" is _exactly_ (and coincidentally) the one described
in the (original) subject of this thread.
I'll go first into the details of it - I owe Ken a thank you and an
explanation, after all.
Then I'll leave it to all of you to ponder
1. If it was really caused by upgrading "in place" (and not plain carelessness)
2. If if was; could the ratio ~ 1/1500 give one the confidence that the
"in place" method is safe, simple and efficient?
3. As an overall "disadvantage" I can see how one might say that "in place"
leads to maybe unnecessary cruft lying around on your system.
But that is part of basic clean-up maintenance that any careful owner should
perform every once in a while.
To Ken,
Thanks for taking an interest in my OP problem. To summarize:
I bitched about a problem (linkage failure) with a missing (undefined) symbol,
__gcc_personality_v0
cropping up on upgrading glibc (from 2.14.1 to the latest, 2.15).
You were right in noticing, "perhaps something is wrong with your
/usr/lib/libgcc_s.so{,.1} symlinks",
except the problem was with a wrong symlink to 'libgcc_eh.a'
(the linker doesn't look for ".so"s here)
Now, the gory details with the smoking gun which might be used in court by
the NEVER-in-place prosecution.
In upgrading to gcc-4.70 (from 4.5.1) prior to the attempt to upgrade glibc
to 2.15, I took a peek at LFS Ch. 5, where I saw this note:
Using --disable-shared means that the libgcc_eh.a file isn't created
and installed. The Glibc package depends on this library as it uses
-lgcc_eh within its build system. This dependency can be satisfied by
creating a symlink to libgcc.a, since that file will end up containing
the objects normally contained in libgcc_eh.a:
ln -vs libgcc.a `$LFS_TGT-gcc -print-libgcc-file-name | sed 's/libgcc/&_eh/'`
So, I took the above as a hint to do on my own the following
cd /usr/lib/gcc/i686-pc-linux-gnu/4.7.0
but BEFORE running the link command (below), I "saved" the 'libgcc_eh.a'
(created by 4.7.0) like so,
mv libgcc_eh.a libgcc_eh.a-4.7.0
and THEN
ln -fs libgcc.a libgcc_eh.a
And therein lay the madness: the "full" 'libgcc_eh.a' was the (only)
place where my "__gcc_personality_v0" was defined.
Obviously, something like
mv libgcc_eh.a-4.7.0 libgcc_eh.a
put finally everything in the right place (and restored my faith in glibc).
Note: now I have to bring in my lawyers to again discuss the ramifications
of sanitizing my headers at this stage :(
The indictment:
Had I taken a closer look at Ch. 6 and started questioning the whys and
wherefores of the missing required symlink instruction of Ch. 5, I'd have
avoided all this headache, the imposition on Ken and frankly this whole
lengthy thread. I can hear the prosecution:
See where working with the wrong pointers "in place" can make the machine
"unusable" (???) !
Pretty serious; at the very least, this reminds one of the old adage,
a wrong pointer has ruined many a good boy.
------
FWIW, an example of the in-place upgrades performed in the last couple of days.
[I included the 'make' time if anybody wants to have an idea as of the size
(and health) of the machine]:
make-3.82 5.3s (this mostly to please Ken who caught me running as ancient
a 'make' version as 3.81)
gdb-7.41 3m2s
glibc-2.15 8m53s
Then, in a real death-defying act, to fully test the sanity of my system,
I even dared the ultimate upgrade,
kernel-3.4.2 5m17s
As a final note, running 'make -k check' on the new glibc-2.15, got me,
grep Error /usr/src/glibc-build/glibc-check-log
make[2]: [/usr/src/glibc-build/posix/annexc.out] Error 1 (ignored)
make[2]: *** [/usr/src/glibc-build/elf/check-localplt.out] Error 1
make[1]: *** [elf/tests] Error 2
and
make[1]: Target `check' not remade because of errors.
make[1]: Leaving directory `/usr/src/glibc-2.15'
make: *** [check] Error 2
after 11m34s of churning around.
Seems pretty OK, after 7 years of heavy abuse, IMHO.
Cheers,
-- Alex
PS On upgrading to kernel 3.4.2, I got
warning: (DRM) selects DMA_SHARED_BUFFER which has unmet direct dependencies
(EXPERIMENTAL),
but I took this as their way to check if I was still paying attention and
not an expression of disgust that I did it in place.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
