From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 90A3EBB91 for ; Wed, 12 Jan 2005 16:46:02 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j0CFk2cZ010971 for ; Wed, 12 Jan 2005 16:46:02 +0100 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 QAA26791 for ; Wed, 12 Jan 2005 16:46:01 +0100 (MET) Received: from yquem.inria.fr (yquem.inria.fr [128.93.8.37]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j0CFjsVW021271; Wed, 12 Jan 2005 16:45:54 +0100 Received: by yquem.inria.fr (Postfix, from userid 18180) id 9186FBB91; Wed, 12 Jan 2005 16:45:54 +0100 (CET) Date: Wed, 12 Jan 2005 16:45:54 +0100 From: Xavier Leroy To: Olivier Andrieu Cc: radugrigore@gmail.com, caml-list@inria.fr Subject: Re: [Caml-list] glibc and ocaml/libasmrun.a Message-ID: <20050112154554.GA8652@yquem.inria.fr> References: <7f8e92aa05011123291c3edfad@mail.gmail.com> <20050112.100059.112626362.oandrieu@nerim.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050112.100059.112626362.oandrieu@nerim.net> User-Agent: Mutt/1.3.28i X-Miltered: at nez-perce with ID 41E5463A.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 41E54632.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 libasmrun:01 runtime:01 libasmrun:01 dlopen:01 ocamlopt:01 runtime:01 bytecode:01 dlopen:01 native-code:01 wrappers:01 ocamlc:01 bytecode:01 compiler:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.0 X-Spam-Level: > This means the runtime (libasmrun.a) contains calls to dlopen(). Now > I'm not sure why there are dlopen's in the native (ocamlopt) > runtime. I thought only the bytecode one is using dlopen (to > dynamically link stub libraries). If that is correct (ie the native > runtime doesn't actually use dlopen) then I guess you can ignore the > warning. This is entirely correct. The reason why the native-code runtime system contains the wrappers around dlopen() is that there exists exactly one ocamlopt-compiled program that needs them: it's ocamlc.opt, the natively-compiled bytecode compiler, which needs to dlopen() shared libraries to check for the existence of symbols referenced from external declarations in the Caml source. So, unless the Caml program happens to embark most of ocamlc (unlikely!), you can safely ignore the warning at static linking time. - Xavier Leroy