From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id C6CDC7EE99 for ; Fri, 27 Dec 2013 15:14:25 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of markus.mottl@gmail.com) identity=pra; client-ip=74.125.82.46; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="markus.mottl@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of markus.mottl@gmail.com designates 74.125.82.46 as permitted sender) identity=mailfrom; client-ip=74.125.82.46; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="markus.mottl@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wg0-f46.google.com) identity=helo; client-ip=74.125.82.46; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="postmaster@mail-wg0-f46.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEDAESKvVJKfVIulGdsb2JhbAA+EAqDQ1WmYYNqjw2BEAgWDgEBAQEHCwsJEiqCJQEBAQQnGQEUBxILAQMMBgULAwoNISEBAREBBQEKEgYTEgiHVQEDEQ02onWMXIMJjyAKGScDCmSESBEBBQyMfoE3XAeENgSJQ4xogWyBMIsqg00YKYR3Hg X-IPAS-Result: AsEDAESKvVJKfVIulGdsb2JhbAA+EAqDQ1WmYYNqjw2BEAgWDgEBAQEHCwsJEiqCJQEBAQQnGQEUBxILAQMMBgULAwoNISEBAREBBQEKEgYTEgiHVQEDEQ02onWMXIMJjyAKGScDCmSESBEBBQyMfoE3XAeENgSJQ4xogWyBMIsqg00YKYR3Hg X-IronPort-AV: E=Sophos;i="4.95,560,1384297200"; d="scan'208";a="50542111" Received: from mail-wg0-f46.google.com ([74.125.82.46]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 27 Dec 2013 15:14:25 +0100 Received: by mail-wg0-f46.google.com with SMTP id m15so8073655wgh.13 for ; Fri, 27 Dec 2013 06:14:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WCPchFMV8Ax8Ty46/NbmDGgbjBhD3vVcYtpNafr5FF8=; b=aQeQnt/5D0mo41hIk62+nW0NHEhONDLV64j/CwWjxcxi3eEiUpRUcBGAfoLlxSvB22 YpCT6k8xbKj6Agh3JX1nSRDMJcxxxByneHzheFXFuaNM2o7Uk+v5mdSGbZvCyw5l5XrX aW08EZfOofpujejHkHmpW4oA+dehE6hftgk/fZJgjwzX/1wASEziMXmaLyu74Oj886LO 3HYZwXJWZBVUsIjbxJ/ccsFbdeldNOeG5VuBtbpbAT3CvIYKowQYf08CMdRU2qx78mKh UzPx1HDAc+powWTIPcAomGvwclfi33ZTOLTbkmBD0sIOhYvRP3bElgDz9nNZkX3wWC0G WHTw== MIME-Version: 1.0 X-Received: by 10.194.20.130 with SMTP id n2mr9342002wje.62.1388153662724; Fri, 27 Dec 2013 06:14:22 -0800 (PST) Received: by 10.195.13.41 with HTTP; Fri, 27 Dec 2013 06:14:22 -0800 (PST) In-Reply-To: <000001cf0307$75fa3520$61ee9f60$@metastack.com> References: <000001cf0307$75fa3520$61ee9f60$@metastack.com> Date: Fri, 27 Dec 2013 09:14:22 -0500 Message-ID: From: Markus Mottl To: David Allsopp Cc: OCaml List Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Libraries exporting external definitions in modules This bug report also describes this problem: http://caml.inria.fr/mantis/view.php?id=4166 I think this should get fixed. Though there is an easy (though slightly less efficient) workaround, this problem is pretty hard to identify, especially for people who have never seen it. Regards, Markus On Fri, Dec 27, 2013 at 8:27 AM, David Allsopp wrote: > I've hit an unexpected gotcha using external declarations in .mli files. > > I have a module where the functions exported are all C stubs and so, knowing > that exposing the external definition in the .mli file allows the compiler > to generate more efficient function calls, I'd exported the functions using > external declarations in the .mli files. > > The module also contains an important piece of initialisation code which > must be run before any of the other functions will work. So, simplified, it > looks like this: > > Foo.ml > ------ > external bar : 'a -> unit = "my_c_implementation_of_bar" > external baz : unit -> unit = "very_important_initialisation_stub" > > let _ = > baz () > > Foo.mli > ------- > external bar : 'a -> unit = "my_c_implementation_of_bar" > > This is then wrapped up in a .cmxa file and the .cmxa, .cmx, .a and .cmi > files installed as normal. Now I produce a program using it: > > Bar.ml > ------ > Foo.bar 42 > > and compile this program using ocamlopt -o fubar foo.cmxa Bar.ml > > When I run it, the initialisation code in Foo.ml calling baz never takes > place (which I can tell because it means that the call to Foo.bar, which > does take place, fails). > > After much head-scratching, I realised that the reason for this is that the > external declaration in Foo.mli means that the module Foo presumably isn't > linked as its code was deemed unnecessary (as it would be if Bar.ml only > referenced types in the module Foo, rather than values). > > So, my question: is that really correct behaviour? I can see why referencing > a type only is not sufficient to cause a module to be linked, but surely > referencing a value (even when it's declared external) should not exempt the > linker from actually linking the module code - at least when the module > contains top-level code (rather than just static values or functions)? > > It seems a shame to slow the calls down (however trivially) by removing the > external declarations from the .mli file (i.e. declaring val bar : 'a -> > unit in the .mli) simply to keep the linker happy. > > > David > > PS I don't expect it's relevant, but for this I was running OCaml 4.01.0 on > Linux/armv6l > > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs -- Markus Mottl http://www.ocaml.info markus.mottl@gmail.com