From: Igor Pechtchanski <pechtcha@cs.nyu.edu>
To: Emir Pasalic <pasalic@cs.rice.edu>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Dynamic linking
Date: Tue, 5 Apr 2005 18:02:58 -0400 (EDT) [thread overview]
Message-ID: <Pine.GSO.4.61.0504051738560.29048@slinky.cs.nyu.edu> (raw)
In-Reply-To: <263b229a999e9788124e5fc0129a814f@cs.rice.edu>
On Tue, 5 Apr 2005, Emir Pasalic wrote:
> We are writing a program that generates a C file, compiles it to a
> dynamic library, and uses dlopen (and such) to load it, execute it and
> bring its value into ocaml (bytecode) runtime. To do this, we need to
> use some of the functionality of the ocaml runtime (e.g., caml_alloc,
> caml_update) so we can marshall values from the C world into the world
> of ocaml. Our solution works on linux and macos platforms, but we have a
> problem trying to make it run on windows with Cygwin.
>
> So, we're trying to create a shared library on Cygwin that contains
> symbols such as "caml_alloc" and "caml_update".
> We do not know of a way to easily incorporate these symbols in the
> linking process, and so they remain undefined when we try to create a
> library, and undefined symbols are not allowed in Cygwin shared
> libraries.
The curent version of O'Caml under Cygwin doesn't support dynamic linking
in any structured way. I was able to build an ad-hoc set of dynamic
libraries for standard modules, but I'm still in the process of modifying
O'Caml tools to do this seamlessly.
That said, there is still a limitation in Windows that any unresolved
symbols in a DLL have to have a *statically* known target, i.e., the
loader has to know what DLL to load the symbols from. The two possible
workarounds are to a) extract the unresolved symbols from the executable
into a helper DLL that both the executable and the library are linked
with, or b) use dlopen/dlsym, as you did.
> Therefore we tried to resort to another method, where the calls to
> caml_alloc and caml_update are replaced by calls to dlopen and dlsym
> functions, i.e., we were trying to do this:
>
> h = dlopen ("<the library name>", RLTD_NOW);
> /* process error */
> s = dlsym (h, "caml_alloc");
> /* process error */
> my_alloc = /* proper casting */ s;
> result = my_alloc ( /* arguments */ );
>
> Assuming that this is possible, what is the name that should be given to
> the library?
Any name will do, as long as LD_LIBRARY_PATH contains the directory of
your library (yes, it *is* used on Cygwin for dlopen calls). It doesn't
even have to end in ".dll".
> Else, is it possible to build a shared library on Cygwin that contains
> references to these symbols?
It is. You'll need to create a helper DLL and an import library for it.
Then link your executable and the library DLL with the helper. I would
have referred you to the (experimental) ocaml-3.08.1-2 cygwin package, but
it apparently wasn't uploaded to the main Cygwin package repository. I
can send you the source/patches if interested.
> Note that all this works perfectly fine on MacOS and linux which allow
> unresolved symbols in dynamic libraries, but Cygwin simply dies. Any
> Windows/Cygwin experts out there who can help us?
I would be willing to help you build a small example app to get you
started. Let me know where to get the source.
Igor Pechtchanski, the volunteer O'Caml maintainer for Cygwin
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ pechtcha@cs.nyu.edu
ZZZzz /,`.-'`' -. ;-;;,_ igor@watson.ibm.com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
next prev parent reply other threads:[~2005-04-05 22:03 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-05 21:12 Emir Pasalic
2005-04-05 22:02 ` Igor Pechtchanski [this message]
2005-09-26 3:09 [Caml-list] " Jonathan Roewen
2005-09-26 4:26 ` skaller
2005-09-26 5:14 ` Jacques Garrigue
2005-09-26 5:20 ` Jonathan Roewen
2005-09-28 9:05 ` Jacques Garrigue
2005-09-28 12:44 Alexander Bottema
2005-10-04 12:47 Alexander Bottema
2005-10-04 14:47 ` skaller
2005-10-04 15:56 Alexander Bottema
2005-10-05 8:14 ` skaller
2005-10-05 13:11 Alexander Bottema
2007-06-15 16:03 Alain Frisch
2007-06-15 16:47 ` [Caml-list] " Joel Reymont
2007-06-15 16:52 ` Brian Hurt
2007-06-15 18:24 ` Alain Frisch
2007-06-15 18:59 ` Jon Harrop
2007-06-15 20:57 ` Alain Frisch
2007-06-15 22:38 ` Quôc Peyrot
2007-06-16 7:23 ` Alain Frisch
2007-06-16 17:33 ` Jon Harrop
2007-06-16 17:59 ` skaller
2007-06-16 20:13 ` Christophe TROESTLER
2007-06-16 23:10 ` Philippe Wang
2007-06-15 22:37 ` skaller
2007-06-15 22:45 ` Christophe TROESTLER
2007-06-15 22:58 ` skaller
2007-06-20 13:40 ` Alain Frisch
2007-06-24 11:35 ` Jon Harrop
2007-06-18 4:18 Jeffrey Loren Shaw
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.GSO.4.61.0504051738560.29048@slinky.cs.nyu.edu \
--to=pechtcha@cs.nyu.edu \
--cc=caml-list@inria.fr \
--cc=caml-list@yquem.inria.fr \
--cc=pasalic@cs.rice.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox