This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: dynamic linking, unexec, and the freezer


From: Andrew Archibald <aarchiba@undergrad.math.uwaterloo.ca>
Andrew> There have been complaints about raw guile's startup time.  For good
Andrew> reason --- on my machine it's about ten seconds.  So somebody grabbed
Andrew> the unexec mechanism from emacs.  This will let you store the state of
Andrew> a program in mid-execution.  Thus you can even execute your own scheme
Andrew> code and save it.
Andrew> 
Andrew> Unfortunately, this means that you can't use a dynamic library in
Andrew> unexeced code --- the dumped executable can't find the library and
Andrew> segfaults.  This limits unexec seriously --- if people want to unexec
Andrew> their guile, they have to statically link any extensions they may want
Andrew> to use from preloaded code.  Unfortunately, this means rewriting both
Andrew> C and scheme code, since the interface to statically linked libraries
Andrew> is totally different from that used for dynamic libs.  

I'm not quite sure why unexec prevents the program from loading dll's.
My emacs uses plenty of shared libs and can load them explicitly using
dlopen() (of Linux/glibc2).

However, I long for the ability to *create* a dynamic library by
unexec.  Imagine if Emacs were a tiny program + unexec'ed shared lib.
Other programs could load it at run time and have access to all of its
functionality.

But the big problem I see with this is relocations.  Presumably, a
shared library doesn't know at what address it will be loaded, so any
data structures that store pointers must be fixed up at runtime.  This
will no doubt involve some dynamic-loader wizardry, but in the same
league as emacs' current unexec technology, I would hope.

-John