This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Unexec gurus?
Sorry to follow up to my own post, but:
"Greg J. Badros" <gjb@cs.washington.edu> writes:
> Russell McManus <russell.mcmanus@msdw.com> writes:
>
> > "Greg J. Badros" <gjb@cs.washington.edu> writes:
> >
<snip>
> > 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)
<snip>
>
> % ldd dumped_tguile
> < same as above, for ldd tguile >
>
> % ldd scwm
<snip>
> libguile.so.6 => /usr/lib/libguile.so.6 (0x40110000)
<snip>
> % 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?
Upon closer inspection of the linking of tguile, I observed that it
does, in fact, include libguile.a in its link line *before* the -lguile
entry. The -lguile entry is thus superfluous (assuming the .a matches
the .so) but results in ldd listing libguile among tguile's shared
object dependences.
The moral of the story:
do not trust that just because a .so is listed in ldd output that the
code of that .so is *not* statically linked. Re-inspect the link lines
instead to determine what's going on.
Now my question becomes: is it a fundamental weakness of unexec/dump
that all code must be statically linked in order to preserve state?
This seems a little counterintuitive because I'd've thought that the
data segments could still be preserved.
Thanks again, Russ, for your help!
Greg