Re: Dynamic loading problem
On Thu, Apr 29 2004, Gregory Wright wrote:
> It has nothing to do with shared objects.
No, it hasn't and I have never claimed that it is so.
> the main program (the one that loads the loadable modules) to explicitly
> link all of the object files that the set {, modules>}
> depends on.
No. The problem isn't this and you need not do that in most cases as
long as you dynamically load the libraries too (which I think you really
should to allow truly dynamic loading not depending on which libraries
you compiled in). The problem is the functions in the RTS that are ffi:ed
into the dynamic loader. They are not "global" symbols on some platforms.
The rts is linked into alls programs by default (so specifying it separatly
is a no-op and waste of time).
I have no problem what so ever with anything _but_ dynamically loading
a module that requires functions from the RTS (i.e. loadObj,
lookupSymbol etc.).
However, I've now found the solution. All that was required was
to give the flag -optl-export-dynamic to ghc, not
-optl--export-dynamic, stupid mistake, but there it is...
Thanks to all that tried to help me!
/Hampus
--
Homepage: http://www.dtek.chalmers.se/~d00ram
E-mail: [EMAIL PROTECTED]
"Det är aldrig försent att ge upp"
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic loading problem
Hi,
I was playing with dynamically loaded modules and had the same problem.
It has nothing to do with shared objects. What you have to do is to
force
the main program (the one that loads the loadable modules) to explicitly
link all of the object files that the set {, }
depends on.
For example, if a module depends on symbols in
/HShaskell98.o,
(but the main program doesn't), you should explicit link
/HShaskell98.o
into the main program.
This happens because when you build your loadable modules the linker
assumes that they will later be linked into a main program, at which
time
all of the undefined references will be resolved. Since you never link
the modules
and main together, some references remain unresolved.
It shouldn't be hard to automate this; a script could run nm on the
module
and main program, make a list of unresolved references, search the files
in to know which object to include, and then relink the
main
program.
If you look at the makefiles in
http://www.algorithm.com.au/wiki/hacking/haskell.ghc_runtime_loading
you'll see some examples of how the main program has to be linked.
Best Wishes,
Greg
On Apr 29, 2004, at 3:24 PM, Hampus Ram wrote:
On Thu, Apr 29 2004, Alastair Reid wrote:
Does passing the flag RTLD_GLOBAL to dlopen help? (man dlopen for
info about
this flag)
No, since none of the objects involved are shared objects (I use
neither
dlopen or addDLL but the loadObj function). They are just compiled
Haskell
modules and the problem lies in the RTS symbols which for some reason
can't
be loaded dynamically (why it doesn't work when the base package etc.
can
be loaded is beyond me).
However when loading shared objects your flag is the one to use. That
works without flaw and is really a nicer way to load shared objects
than
the RTS function addDLL.
/Hampus
--
Homepage: http://www.dtek.chalmers.se/~d00ram
E-mail: [EMAIL PROTECTED]
"Det är aldrig försent att ge upp"
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic loading problem
On Thu, Apr 29 2004, Alastair Reid wrote: > Does passing the flag RTLD_GLOBAL to dlopen help? (man dlopen for info about > this flag) No, since none of the objects involved are shared objects (I use neither dlopen or addDLL but the loadObj function). They are just compiled Haskell modules and the problem lies in the RTS symbols which for some reason can't be loaded dynamically (why it doesn't work when the base package etc. can be loaded is beyond me). However when loading shared objects your flag is the one to use. That works without flaw and is really a nicer way to load shared objects than the RTS function addDLL. /Hampus -- Homepage: http://www.dtek.chalmers.se/~d00ram E-mail: [EMAIL PROTECTED] "Det är aldrig försent att ge upp" ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic loading problem
> The functions from the rts are ffi:ed into my program but when
> dynamically loading the module, these functions can't be found
> ("unknown symbol `lookupSymbol`") and neither can I load the
> HSrts.o package to make them visible due to duplicate functions
> ("I found a duplicate definition for symbol makeStableNamezh_fast").
> How can I proceed? Can I pass some flag to the linker or such to force
> them to behave as I want?
Does passing the flag RTLD_GLOBAL to dlopen help? (man dlopen for info about
this flag)
--
Alastair Reid
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Dynamic loading problem
Hi,
by using the RTS I've made it possible to dynamically load modules for
quite some time now. However, recently I've stumbled inte quite a
problem.
I've created a bunch of modules to handle all dynamic loading for me and
things are good for simple programs. But now I want to load my dynamic
loading modules dynamically (yes, it sounds weird) and that can't be
done - not on linux anyways.
The functions from the rts are ffi:ed into my program but when
dynamically loading the module, these functions can't be found
("unknown symbol `lookupSymbol`") and neither can I load the
HSrts.o package to make them visible due to duplicate functions
("I found a duplicate definition for symbol makeStableNamezh_fast").
How can I proceed? Can I pass some flag to the linker or such to force
them to behave as I want?
I only have this problem with linux (tested on Debian and Redhat)
using ghc 6.2.1. On Solaris everything works just great (one doesn't
even have to load any extra packages there) with ghc 6.0.1.
/Hampus
ps. my library can be found at
http://www.dtek.chalmers.se/~d00ram/dynamic/
--
Homepage: http://www.dtek.chalmers.se/~d00ram
E-mail: [EMAIL PROTECTED]
"Det är aldrig försent att ge upp"
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: turn off let floating
Hi, > > Results: > > > >method runtime (s) > >--- > >pure0.7 > >ffi 3.2 > >fastMut 15 > >ioref 23 > > I very strongly suspect that it is the unsafePerformIO that hurts > performance in the fastMut case. Otherwise this case would be around > the same speed as the FFI example, perhaps faster. > > You could try out that theory by copying the definition of > unsafePerformIO into your code, and putting an INLINE pragma on it. I > think it's safe to do this in your case (it's not safe in general). That's interesting for me, in which situations isn't it safe to inline the definition of unsafePerformIO? David ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
