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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id ACD3B7EE79 for ; Mon, 16 May 2016 03:10:25 +0200 (CEST) IronPort-PHdr: 9a23:XJoNmBImom58n+BlbdmcpTZWNBhigK39O0sv0rFitYgVKvrxwZ3uMQTl6Ol3ixeRBMOAu6MC0bed7/yocFdDyKjCmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TWM5DIfUi/yKRBybrysXNWC3oLtiqvup9X6WEZhunmUWftKNhK4rAHc5IE9oLBJDeIP8CbPuWZCYO9MxGlldhq5lhf44dqsrtY4q3wD89pozcNLUL37cqIkVvQYSW1+ayFm0vb2rgHORhej4X4VU2Ne0kYZQluN0BavZJD7vzHmsaJR2WGxOtbzSvhgQzOo4r13TzfkiSwALDs+tmbNhZojorhcpUeOrhZlwoPQKLqeNPdkc7mVKdwTT3BAU8IXTCdBD5mxdaMACuMAOaBTqIyr9AhGlge3GQT5XLCn8TRPnHKjmPBj3g== Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=gabriel.scherer@gmail.com; spf=Pass smtp.mailfrom=gabriel.scherer@gmail.com; spf=None smtp.helo=postmaster@mail-io0-f170.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.223.170; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.223.170 as permitted sender) identity=mailfrom; client-ip=209.85.223.170; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-io0-f170.google.com) identity=helo; client-ip=209.85.223.170; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-io0-f170.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CdAACFHTlXiKrfVdFDGoNVN3gGBqcdgVOFY4Mzh1gBDYF2IoVvgRUHOBQBAQEBAQEBAREBAQEICwsJHzGCLYIXARYRBBkBFAcSCwEDEhANAgIJFgcCJAERAQUBChgTCAoMBIdyAQMXCQUsnk+BMT4xizuBaoJYBYZ7ChknAwpSg1UBAQEBAQEEAQEBAQEBGQIGEHGFJIheEQGDHIJZBYY7DIE3kCmBLyeEKIVlgjuCADeCKoo4hn9eE4YTEh6BDh4BAYI7DREKFoFRIDIBhlCBNQEBAQ X-IPAS-Result: A0CdAACFHTlXiKrfVdFDGoNVN3gGBqcdgVOFY4Mzh1gBDYF2IoVvgRUHOBQBAQEBAQEBAREBAQEICwsJHzGCLYIXARYRBBkBFAcSCwEDEhANAgIJFgcCJAERAQUBChgTCAoMBIdyAQMXCQUsnk+BMT4xizuBaoJYBYZ7ChknAwpSg1UBAQEBAQEEAQEBAQEBGQIGEHGFJIheEQGDHIJZBYY7DIE3kCmBLyeEKIVlgjuCADeCKoo4hn9eE4YTEh6BDh4BAYI7DREKFoFRIDIBhlCBNQEBAQ X-IronPort-AV: E=Sophos;i="5.24,625,1454972400"; d="scan'208";a="177894509" Received: from mail-io0-f170.google.com ([209.85.223.170]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 16 May 2016 03:10:24 +0200 Received: by mail-io0-f170.google.com with SMTP id i75so187973805ioa.3 for ; Sun, 15 May 2016 18:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=dAZBuWigUDYjQ4BaL3OMhttKfv+1H95Uee6d8R2gafg=; b=N1AZKjahUAxG8A7p9nMOvyosWqVkU3cvanmaw8VAEQgLqpHph8H2JQ1L2IxFye/JEL Pt5bu8hspcG1iJnMtpGuiANiUExazRNTnusMK2VTyKaNWMZKntyXo9gz62iOu7AwXg39 Ii7KhDti1c9MoYb8E3E+1lmtyH6a1jS1lzqEflRcQIF1oj+uIQ6F9F3T2FNpfc0TjQns a9rDXBNLS8eWpd0+mMEmq02zuDlSYy6vqAc+oBsOBb+k/oA4p3P7k/nSvvDxjHHFo949 fPXxeDsvVHu0KDAk/ouOZ4W5gZHK/SATCiTjRK+9iHjkVJwnZLYW1Kkaqjb6XPvSIXk2 cWbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=dAZBuWigUDYjQ4BaL3OMhttKfv+1H95Uee6d8R2gafg=; b=ilsENqi7y9bRPwDffziZ73lU5olX0Wn7yjBjmRyOZfnfw9N1Plrno9Oyr+ZdTtN4w/ Ynu2CqywcQctz00PlI53r308DJTER8GhJIOuPnOFfubCdLjqyXx2dTWGKbRIDmTscYPu pLwjH904+oQpCpI5/KYiXOAXl+Pupahu/3LnQ7qcLzA6Nbav1urtIZ73jvP9P0/7lobp Fbp1nVIdht3bgYUjZkQ4zQtaiVkVuCSkIIC29n53b/TOMH08xB8zwQ1A4Z0o1u1wBpJ8 k3Dp1j9fhN+mW+cRpLFb2NsotGxStkn2f14M9kgk7gne7ECls47IAiY8GAGr83IC51on 7CQg== X-Gm-Message-State: AOPr4FWfolp+9PWa9XsnBHKIrYZhyPIphXAt1hFKCjGex/JweLurpl6ttNZ5flymMioRn9L4+Ry1X59LqSLgLA== X-Received: by 10.107.169.13 with SMTP id s13mr17058613ioe.19.1463361022726; Sun, 15 May 2016 18:10:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.89.195 with HTTP; Sun, 15 May 2016 18:09:43 -0700 (PDT) From: Gabriel Scherer Date: Sun, 15 May 2016 21:09:43 -0400 Message-ID: To: Roberto Di Cosmo Cc: Leo White , caml users Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Caml-list] Justifying a breaking 4.03 change, strong dependency on modules with "external" declarations (was: ) As Roberto Di Cosmo points out in the thread "parmap package broken in opam switch 4.03.0", using an "external" declaration provided by a module A now counts as a dependency on A -- in particular, A has to be linked in the final executable. This breaks some user code (such as Parmap, but I heard reports from other breakages) in the case where A was used solely to provide such "external" declarations, for C functions implemented in a C stub that was linked in the application. In that case it was neither necessary nor useful to link A, and projects did not do it. They need to do it explicitly now, and break at linking-time otherwise. I realize that users may not understand why this change, which looks like a regression, happened in 4.03. It is actually a bugfix, see PR#4166 ( http://caml.inria.fr/mantis/view.php?id=3D4166 ): if A does not only provide those external declarations, but also initializes some state that the C functions rely on (such as exception declarations), then forgetting to link A may result in a crash at runtime. In other words, the pre-4.03 situation could result in some rare cases of user error in a very subtle, very difficult to understand bug. Under 4.03, such difficult errors cannot happen anymore, but we have broken some (edgy but) less uncommon existing patterns in the transition. On the long term, this is a win (obvious errors are linking time are better than subtle errors at runtime), but the transition period is of course painful -- and maybe it could have been managed better, eg. with a warning instead of an error for the next version, but this is a lot of work. ## Recovering the justification In case anyone wonders, here is how I obtained this explanation: the Changes file ( https://github.com/ocaml/ocaml/blob/trunk/Changes ) lists the breaking change as * PR#4166, PR#6956: force linking when calling external C primitives (Jacques Garrigue, reports by Markus Mottl and Christophe Troestler) (Note the bullet point "*" instead of "-", that indicates that this change may break user programs. If you maintain large or old OCaml codebases, it is a good idea to review each starred item of the changelog after each release. If a program breaks after a new release, looking at the starred items may give indications of what is happening.) The first of the two issue reports listed in the Changes is an example of the subtle bugs that could happen with the pre-4.03 semantics, reported by Markus Mottle. The second is another instance reported by Troestler, and contains the discussion around the change and its implementation, mainly by Jacques Garrigue that did the implementation work. On Wed, Apr 27, 2016 at 5:49 AM, Roberto Di Cosmo wro= te: > Indeed, after some more investigation (thanks to Francois Berenger), it > seems that in 4.03 we can no longer just use a bare .mli file with the > interface to some external code, as it was possible before. > > Now, we need to provide also an .ml file, in any case. > > The fix in parmap is underway, and it was a simple matter of moving > setcore.mli to setcore.ml, without touching anything else. > > For the curious, the content of setcore.ml (ex setcore.mli) is the > following: > > (* uses the native affinity interface to > declare that the current process should be > attached to core number n *) > > external numcores: unit -> int =3D "numcores" > external setcore: int -> unit =3D "setcore" > > If you have similar patterns in your projects, take due notice :-) > > -- > Roberto > > > 2016-04-26 19:16 GMT+02:00 Leo White : >> >> > It seems that in 4.03 one needs to add the -opaque flag when compiling >> > such stubs, otherwise things go astray, and it seems ocamlbuild does n= ot >> > detect automatically such situations, so one needs to explicitly pass >> > the -opaque option when compiling setcore.mli (and only it). >> >> I would not have thought that adding `-opaque` would be sufficient. It >> should get you >> past the compilation of modules which depend on `setcore.mli`, but I wou= ld >> expect >> linking to fail still. If that is not the case I guess it should be >> considered a bug because >> in 4.03 referencing an `external` is supposed to force linking of the >> containing module. >> The change was made because the existing behaviour was said to confuse >> people -- >> using a normal value from a module caused it to get linked whilst using = an >> external value >> didn't. >> >> Regards, >> >> Leo >> >> -- >> 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 > > > > > -- > Roberto Di Cosmo > > ------------------------------------------------------------------ > Professeur (on leave at/detache a INRIA Roquencourt) > IRIF email : roberto@dicosmo.org > Universite Paris Diderot web : http://www.dicosmo.org > Case 7014 Twitter : http://twitter.com/rdicosmo > 5, Rue Thomas Mann > F-75205 Paris Cedex 13 FRANCE > ------------------------------------------------------------------ > Office location: > > Paris Diderot INRIA > > Bureau 3020 (3rd floor) Bureau C123 > Batiment Sophie Germain Batiment C > 8 place Aur=C3=A9lie Nemours 2, Rue Simone Iff > Tel: +33 1 57 27 92 20 Tel: +33 1 80 49 44 42 > > Metro > Bibliotheque F. Mitterrand Ligne 6: Dugommier > ligne 14/RER C Ligne 14/RER A: Gare de Lyon > ------------------------------------------------------------------ > GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3