From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA16310; Thu, 14 Nov 2002 19:23:31 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA16303 for ; Thu, 14 Nov 2002 19:23:30 +0100 (MET) Received: from relay.pair.com (relay1.pair.com [209.68.1.20]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id gAEINSX24938 for ; Thu, 14 Nov 2002 19:23:29 +0100 (MET) Received: (qmail 89380 invoked from network); 14 Nov 2002 18:23:24 -0000 Received: from arda.pair.com (HELO compaqreview.d6.com) (209.68.1.133) by relay1.pair.com with SMTP; 14 Nov 2002 18:23:24 -0000 X-pair-Authenticated: 209.68.1.133 Message-Id: <4.3.2.7.2.20021114100219.041968b0@localhost> X-Sender: checker@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Nov 2002 10:21:12 -0800 To: Xavier Leroy From: Chris Hecker Subject: Re: [Caml-list] ocamlc linking loads dlls? Cc: caml-list@inria.fr In-Reply-To: <20021114160348.B9597@pauillac.inria.fr> References: <4.3.2.7.2.20021113221318.03f89028@localhost> <4.3.2.7.2.20021113221318.03f89028@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > > 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