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 681F87F706 for ; Sat, 28 Dec 2013 15:40:34 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=pra; client-ip=212.227.17.8; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=mailfrom; client-ip=212.227.17.8; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of postmaster@moutng.kundenserver.de designates 212.227.17.8 as permitted sender) identity=helo; client-ip=212.227.17.8; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="postmaster@moutng.kundenserver.de"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoBABnivlLU4xEIm2dsb2JhbABYg0O6MYEVFg4BAQEBAQYLCwkUKIImAQEEJy4kEAsOOFcGEwmHfwnJJheJU4UkJgeCLoIIBI8Gj1EFjn0 X-IPAS-Result: AvoBABnivlLU4xEIm2dsb2JhbABYg0O6MYEVFg4BAQEBAQYLCwkUKIImAQEEJy4kEAsOOFcGEwmHfwnJJheJU4UkJgeCLoIIBI8Gj1EFjn0 X-IronPort-AV: E=Sophos;i="4.95,566,1384297200"; d="asc'?scan'208";a="50652610" Received: from moutng.kundenserver.de ([212.227.17.8]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 28 Dec 2013 15:40:33 +0100 Received: from office1.lan.sumadev.de (dslb-178-004-029-028.pools.arcor-ip.net [178.4.29.28]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MalH0-1WBhpS31p4-00Jw7r; Sat, 28 Dec 2013 15:40:32 +0100 Received: from [192.168.0.146] (546BEFE6.cm-12-4d.dynamic.ziggo.nl [84.107.239.230]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id 4727EC00D3; Sat, 28 Dec 2013 15:40:32 +0100 (CET) Message-ID: <1388241631.2837.7.camel@e130> From: Gerd Stolpmann To: David Allsopp Cc: OCaml List Date: Sat, 28 Dec 2013 15:40:31 +0100 In-Reply-To: <000001cf0307$75fa3520$61ee9f60$@metastack.com> References: <000001cf0307$75fa3520$61ee9f60$@metastack.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-b93/i9MpLcJ6jDjKcSLI" X-Mailer: Evolution 3.2.3-0ubuntu6 Mime-Version: 1.0 X-Provags-ID: V02:K0:pFes5VEauwUwRlH8a0J2j8kc+riLtnJFzmSFIKAvKx5 bByiPHWAS09npg8gejt7VLulKV1YZZ0zsVBdabaLXmAQP/eHN1 rZqN2zrZ0bziZoggmMu4M0ZB9AUQY9fPwVd/qoZ/Ypm8QX4FrT VOuauj/irTXcFhULUQEVBJMNTsnMbVGt5e38xQFljW8tGs2/XA AVqh9hy6O/3MLjIol4qo02qMlbU69OHOziok7LhVBMDgRe7v8o mQqoEcfhncc+ArOYZe+AJIoRKb/BrAnH9bmXOS7wDfJrNiDYwx BaSZi2xMrHEXZI6grCFKCb6KJh45OjLvor8Wr5X9/fpYU4lFcp 3K8dqv7mcX6jTu2qFUsM= Subject: Re: [Caml-list] Libraries exporting external definitions in modules --=-b93/i9MpLcJ6jDjKcSLI Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable There is an easy workaround: Don't put the external declaration into the mli, just a val. When installing the library, take care to also include the cmx file. This way, the extra function wrapper can be eliminated by the automatic inliner of ocamlopt. Of course, this works only for native code. Gerd Am Freitag, den 27.12.2013, 13:27 +0000 schrieb David Allsopp: > I've hit an unexpected gotcha using external declarations in .mli files. >=20 > I have a module where the functions exported are all C stubs and so, know= ing > that exposing the external definition in the .mli file allows the compiler > to generate more efficient function calls, I'd exported the functions usi= ng > external declarations in the .mli files. >=20 > 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: >=20 > Foo.ml > ------ > external bar : 'a -> unit =3D "my_c_implementation_of_bar" > external baz : unit -> unit =3D "very_important_initialisation_stub" >=20 > let _ =3D > baz () >=20 > Foo.mli > ------- > external bar : 'a -> unit =3D "my_c_implementation_of_bar" >=20 > 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: >=20 > Bar.ml > ------ > Foo.bar 42 >=20 > and compile this program using ocamlopt -o fubar foo.cmxa Bar.ml >=20 > 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). >=20 > After much head-scratching, I realised that the reason for this is that t= he > 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). >=20 > So, my question: is that really correct behaviour? I can see why referenc= ing > 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)? >=20 > It seems a shame to slow the calls down (however trivially) by removing t= he > external declarations from the .mli file (i.e. declaring val bar : 'a -> > unit in the .mli) simply to keep the linker happy. >=20 >=20 > David >=20 > PS I don't expect it's relevant, but for this I was running OCaml 4.01.0 = on > Linux/armv6l >=20 >=20 --=20 ------------------------------------------------------------ Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de My OCaml site: http://www.camlcity.org Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de ------------------------------------------------------------ --=-b93/i9MpLcJ6jDjKcSLI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAABAgAGBQJSvuLfAAoJEAaM4b9ZLB5TcLgIAJbyxJHcOs4sAQ5Icy/mnOja MDM5smdNHtlnqBb+AzdJJjzEIz0tStimCLA4BQ6d8IlxnyJlQHRPHg0PM7bRTxcM 4tKDMfcXlqS1O9sZKkmsr9mD9b4CKmdKgp4FM4XXJUwTREMNf2qh/ONwe73IgXFW sryJJqbKt2ajVh44jgmwEQtXP7EcmOn4IuukM2WwFUKXX02LmMkG9LUgjKgppLOz IGRrQZy+Kt7z9MbS+dOKrALpPaDS5nJdQL3XomeVDI3WtHxu1sKTaXm53I3VK/f+ 3/hlWu1hyGyGwHtWXbL+XGARb3NBbZVaF2liyvVaLOQrnchKm7rbYn/7m6nthCg= =4DUJ -----END PGP SIGNATURE----- --=-b93/i9MpLcJ6jDjKcSLI--