When I define an > externally visible variable saved_termios in Hugs' machdep.c like > RtsStartup.c does, the dlopen used in Hugs is unhappy with > System/Posix/Internals.so (which contains a reference to saved_termios): > > undefined symbol: saved_termios
Initial hypothesis: dlopen and the linker give you some crude control over which symbols are visible to subsequently loaded libraries. According to the man page: The flag RTLD_GLOBAL (which Hugs sets if the symbol is defined in dlfcn.h) says that the symbols in the library being loaded should be visible to any libraries loaded later. If we linked Hugs using the -rdynamic flag (on Linux), then symbols in the Hugs executable would be visible. From your report of success using getters and setters though, it sounds as though functions are always visible but variables are not - so that's not the problem. We could try to figure out what was going wrong but we'd then have to repeat that process for Windows, HPUX and, perhaps, for different implementations of dlopen. (I have some theories based on how dynamic linking of variables is implemented on non-Windows machines which we could pursue or I could explain if you're interested.) Instead of doing that though, I think we should limit ourselves to using the most minimal, most portable subset of dynamic linking functionality we can get away with. At present, the subset being used is as follows: The module being loaded should only access Hugs internals by calling functions that were handed to the module when the module was initialized (this is the HugsAPI structure defined in HsFFI.h). I think this can be implemented on any platform that provides dynamic linking (and it has the added benefit that we're clear what functions are exported) but it may be overly restrictive. As you've found out, it is also possible to access functions using foreign import declarations (at least, this is tru on some platforms). This is a damn sight easier than adding them to HugsAPI but I suspect that we'll need to find some funny linker flags on some platforms (like -rdynamic) to make it work everywhere. In conclusion, I think you should not try to push harder to access the variable directly, that you should use foreign import to access getter/setter functions, and that we should consider adding the getter/setter functions to HugsAPI if we run into portability problems. -- Alastair Reid www.haskell-consulting.com _______________________________________________ Cvs-libraries mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-libraries
