[...] 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.
Strangely enough, adding -rdynamic (or equivalently -Wl,--export-dynamic or -Wl,-E) solves the problem with the variable on my x86 SuSE 8.2 Linux. From ld's man page:
-E
--export-dynamic
When creating a dynamically linked executable, add all
symbols to the dynamic symbol table. The dynamic sym�
bol table is the set of symbols which are visible from
dynamic objects at run time. If you do not use this option, the dynamic symbol
table will normally contain only those symbols which
are referenced by some dynamic object mentioned in the
link. If you use "dlopen" to load a dynamic object which
needs to refer back to the symbols defined by the pro�
gram, rather than some other dynamic object, then you
will probably need to use this option when linking the
program itself.Reading this and looking at the output of "objdump -T hugs" with and without -rdynamic, I don't even understand why the getter/setter approach works. %-]
[...] 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.
OK, I'll proceed as you propose...
Cheers, S.
_______________________________________________ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc
