[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: fsck seg fault failure on vmware -i386?
Date: Fri, 12 Feb 2010 13:27:44 -0000
| After waaay to long, I finally got my VM rebuilt using -current from
| 1/15/2010. It sure would be nice if there was some sort of nuclear
| cvs command to ignore all conflicts and just make my stinkin' tree
| look like the source tree.
Yes, it would be nice ... the way we usually do that (or at least the
way I usually do) is just to rm -fr what I had there, and cvs co all
Otherwise, just removing any files that have conflicts (or even report 'M'
(local mods merged) from cvs), and re-run the update (cvs will complain
about "lost" files, then replace them) works as well. If there are only
a handful of local mods that you want to obliterate, and you can find them
easily, this can be quicker.
| - I've compiled libc with DBG=-g in the libc Makefile.
| o This did not produce libc_g.a in /usr/obj/lib/libc
No, I don't see anything that would ever make an _g.a version of the
library, I think whoever suggested that might have been mistaken.
| o This did produce a libc.a that was about 2x the size
| of/lib/libc.a so I assume it has symbols and is debug (?)
Maybe, you could test with
and see what it says - expect lots of output. if all you get is
undefined symbols (U), and T D W and B (capital letter) types, then
you don't have the debug. If debug is there you should also see lots of
stuff with lower case letter types (t d ...) You don't have to look
through all the output, the first function or two should be enough to tell.
I'd also have suspected rather more than twice the size- gdb symtabs (the stuff
the -g option produces) tend to be huge. What might have happened here,
is that DBG=-g turns off -O (compiler optimisation) - which is generally a
good thing, it makes debugging easier, the optimiser can confuse gdb,
but that would make the objects bigger, and I could believe twice as big
(though that is quite a lot.)
But, when building the .a libraries, the make scripts clean up the symbol
tables by default, unless -g is in COPTS - what's in DBG goes into CFLAGS
not into COPTS (COPTS also goes in CFLAGS, and what ends up in CFLAGS is what
the compiler gets). That's most likely a bug in bsd.lib.mk (or it might be
a design choice, sometimes it is hard to know).
Anyway, I suspect that perhaps the DBG=-g way of compiling with -g
might have been the wrong way, the library would have been compiled with
-g (and no -O options), and then all the symbols carefully added, thrown
away as COPTS doesn't contain -g. The COPTS+=-g might have worked a lot
better (though that way doesn't disable optimisation). But without looking
at the libc.a that you have I can't be certain, But I kind of suspect
that you might need to build again.
| - I've compiled fsck_ffs with CPPFLAGS+= -g and
| DPADD+=/usr/obj/lib/libc/libc.a in the Makefile
If that finished without errors, that's a good sign (it shoes that
the process was OK). If you run
nm fsck_ffs | grep localtime
you should see something like
0804abd0 T locatime
(not at that address, of course), that indicates that you have localtime
from the static library. If you see
instead, that means the static library didn't get used, and localtime will
come from the shared libc at runtime. You want the T version!
This is a test you can do now, for this it doesn't matter whether the
gdb symbols remained in that libc.a or not to find out if fsck_ffs built
the way we want it to.
| - I've run: ldd ./fsck_ffs which gives
| o ./fsck_ffs:
| -lc.12 => /lib/libc.so.12
| -lutil.7 => /lib/libutil.so.7
| -lprop.1 => /lib/libprop.so.1
| o Should I be concerned that -lc is still referenced rather
| than my debug version which I manually linked in?
Not necessarily - cc adds "-lc" anyway, which would find the shared version,
so this isn't necessarily a problem (libutil and libprob, those other
libraries, would need the shared libc). I suspect that this one should
be OK (having two versions of the library could be a problem, but I doubt
it will do any harm here).
| - I've run: ldd /usr/bin/gdb which gives:
| o /usr/bin/gdb:
| -lc.12 => /usr/lib/libc.so.12
| -ltermcap.0 => /usr/lib/libtermcap.so.0
| -lcurses.7 => /usr/lib/libcurses.so.7
| -lintl.1 => /usr/lib/libintl.so.1
| -lm.0 => /usr/lib/libm387.so.0
| -lm.0 => /usr/lib/libm.so.0
| -lkvm.6 => /usr/lib/libkvm.so.6
| o Some of these are common in /lib some not.
The stuff that's common is really in /lib - eg: /usr/lib/libc.so.12
doesn't really exist (well, it does, but just as a symlink to
/lib/libc.so.12.N) The libraries have entries in /usr/lib so everything
can be found there, but they have to actually be in /lib so they're
available to commands that run in single user mode. If you were to
run ldd on something in /bin or /sbin you'd see that it refers to
/lib/libc.so.12 because /usr might not be around when the program is run).
For example, fsck_ffs above - it used /lib/libc.so
| o Do I just need to move these (and associated/corrected links) to
No, that's both too hard to do correcty, and too likely to go wrong
(and then you'd need to convince gdb to look in /lib for its libraries
instead of /usr/lib where it was told to look). Not worth the hassle.
| Or do I create a temp directory at root and create a temporary
| /usr/lib directory once I come up in single user without the real
| /usr partition mounted?
That's what I'd do, every time. It's easier. You can copy all of
/usr/lib if you prefer, it won't do any harm, I'd use
cd /usr && pax -rw -pe lib /temp
(after making /temp). That should copy everything from /usr/lib to
/temp/lib including correctly copying the symlinks, and getting all
permissions etc right. Don't forget to also copy the termcap database
from /usr/share/misc/termcap* (those files you can just cp easier.)
Then in single user mode
mount -u -w /
(after a fsck if one is needed on the root - if the root filesys is
the one with the problems, this gets harder...)
mv /temp/lib /usr/lib
(and mv the termcap database too).
before that, /usr should have been an empty directory. There's no
need (except to recover the space) to ever clean this up, when /usr
is mounted, the stuff in /usr/lib underneath just "vanishes" - if you
do want to recover the space, you need to do that in single user mode
(with /usr not mounted) too.
Main Index |
Thread Index |