cvs

[Alastair Reid]

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