Re: [Caml-list] ocamlc linking loads dlls?

[Chris Hecker <checker@d6.com>]

> > ocamlopt doesn't do it, for what it's worth.
>Sure: ocamlopt links statically the Caml/C stub code.  It doesn't use
>the DLLs.

Right, but the problem I'm running into is I've got a C interface library 
between caml and another C dll, and that interface is compiled to a DLL on 
bytecode builds (like it's supposed to be since you implemented 
cma+dll).  The interface defines all the caml functions, but it in turn 
loads the C dll when it's loaded during link because it's a 
dependency.  So, the problem dll isn't even a dll that's needed by caml 
directly, but it's getting loaded anyway.  This could get really bad in the 
case of a big set of dependencies.  Or, imagine the case where there was a 
strict ordering of DLLs that needed to be loaded or another process that 
had to be running that the dllmain connected to, and it failed dllmain if 
that process wasn't running (like a license server).

> > a) dlls that aren't in the path during build, and
> > b) dlls that do complex stuff in their dllmain
>I agree b) is a bit of a problem, but I don't know of any portable way
>to test whether DLL x.dll defines symbol "foo" than to link x.dll and
>query the address of "foo".

I actually think a) is important as well, for modularity reasons.  In my 
above case, the interface dll only needed the import library from the C dll 
to link since it was done with the C linker.  This means I don't even need 
access to the real C dll to build, just its import library and a 
header.  In the case of something restrictive with security or licenses, I 
might not even have the C dll around until I move onto a test machine or 
something.

There's also the security problem of a _link_ now can run arbitrary code 
because the dllmain gets called, but I didn't bother mentioning that before 
because it's not like caml is trying to be high-security.  However, it is 
still an issue (imagine an app that needs to be built as root but run as 
another user...the dllmain is now run as root by ocamlrun...very irregular).

I understand your desire to fail early during link instead of at runtime, 
but I think this solution causes more problems, and more serious problems, 
than it solves.  Plus, the app will fail at load time, not in the middle of 
running (usually the cmas are all resolved at load, right?), and developers 
are "used to" dll's failing at load time during test if there's a 
versioning issue or something.

If you really must check this at link time (like I said, it's a worthy 
goal, it's just a question of tradeoffs), the right thing to do is write 
the imagehlp code to check the export without loading the dll.  It's pretty 
short.  I assume there's a similar thing on unix.  Until that code gets 
written, I think the better tradeoff is to disable checking during link.

Chris


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners