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] |
> > This confused me too when I first heard it claimed, "unexec and shared > > libs don't mix". I think he means that you can't create a dynamic > > library from a heap image, an assertion which I still dispute. > > Well, the current state of affairs with guile-unexec is that when > memory is dumped, there must be no dynamically-linked code in use, > because when the executable is pulled off disk, any atempt to > reference anything in the dynamic library produces a segfault. This > was observed on GNU/Linux with libc5. This is a pain; I don't know if > it can be fixed in general. > > Andrew Ah, I think you are referring to dynamically-loaded code which interacts with the scheme interpreter (registers smobs, stores objects in the symbol table, etc.) I can see how that wouldn't go well with an unexec'ed binary. The library would be loaded at a different address, and certain types of pointers would become invalid. But presumably, this doesn't affect libraries (such as libc) that were linked with the bare guile the way X11 and the rest are linked with emacs. Under my plan, you would have to link your C modules together with the core into a single dynamic library, then unexec it. You'd have a different (large) lib.so for each interpreter-state you wish to freeze. The standard libguile.so would have boot9 loaded, for example. It's not as modular as it could be, but improvements would involve merging symbol tables and the like, which I don't know how to do. -John