Re: Unexec gurus?

["Greg J. Badros" <gjb at cs dot washington dot edu>]

Russell McManus <russell.mcmanus@msdw.com> writes:

> "Greg J. Badros" <gjb@cs.washington.edu> writes:
> 
> > HOWEVER, when single-stepping through tguile-dumped and scwm-dumped in
> > GDB, there is an important behavioural difference that I cannot explain:
> > In starting the dumped executables, Guile's init.c's scm_boot_guile_1,
> > the "static int initialized" variable that is used there does not appear
> > to have the value "1" for the dumped scwm, but does for the dumped
> > tguile.  Both did set that variable correctly when dumping, but Scwm's
> > dumped executable somehow has lost that state. I'm looking for
> > suggestions for why that might be.
> 
> Are you statically linking in libguile.a?  I know it's a simple one,
> but it got me in the past.  If your dynamically linking libguile.so,
> that variable gets whacked.  My memory here is fuzzy, I hope this
> helps.

I had that thought too, but no, I'm not statically linking to libguile,
but neither is tguile (but read below for more):

% ldd tguile
        libguile.so.6 => /usr/lib/libguile.so.6 (0x4001a000)
        libdl.so.2 => /lib/libdl.so.2 (0x40088000)
        libm.so.6 => /lib/libm.so.6 (0x4008b000)
        libc.so.6 => /lib/libc.so.6 (0x400a8000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

% ldd dumped_tguile
< same as above, for ldd tguile >

% ldd scwm
        libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4001a000)
        libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40023000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4003a000)
        libXtst.so.6 => /usr/X11R6/lib/libXtst.so.6 (0x40047000)
        libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x4004c000)
        libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x4005f000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4006c000)
        libguile.so.6 => /usr/lib/libguile.so.6 (0x40110000)
        libdl.so.2 => /lib/libdl.so.2 (0x4017e000)
        libqt.so.1 => /usr/lib/libqt.so.1 (0x40182000)
        libm.so.6 => /lib/libm.so.6 (0x40342000)
        libcassowary.so.0 => /usr/lib/libcassowary.so.0 (0x4035e000)
        libGTL.so.3 => /usr/contrib/lib/libGTL.so.3 (0x40427000)
        libImlib.so.1 => /usr/lib/libImlib.so.1 (0x4049b000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x404c6000)
        libtiff.so.3 => /usr/lib/libtiff.so.3 (0x404e6000)
        libungif.so.4 => /usr/lib/libungif.so.4 (0x40513000)
        libpng.so.2 => /usr/lib/libpng.so.2 (0x4051b000)
        libz.so.1 => /usr/lib/libz.so.1 (0x40538000)
        libc.so.6 => /lib/libc.so.6 (0x40547000)
        libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40635000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
        libstdc++-libc6.1-1.so.2 => /usr/lib/libstdc++-libc6.1-1.so.2 (0x40682000)

% ldd dumped_scwm
< same as above, for ldd scwm >

BUT: because you suggested it, too, I decided to do the obvious
experiment, and I linked scwm statically against libguile.a (instead of
-lguile in the libtool link line).  My simple test succeeded there!

What gives?  Why can tguile get away with dynamically linking against
libguile.so, but my scwm test case cannot?

Thanks, Russ;  there is still a mystery afoot, though!

Greg