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 B5A187EF28 for ; Fri, 26 Jun 2015 23:27:50 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of edwin+ml-ocaml@etorok.net) identity=pra; client-ip=62.210.252.135; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="edwin+ml-ocaml@etorok.net"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of edwin+ml-ocaml@etorok.net designates 62.210.252.135 as permitted sender) identity=mailfrom; client-ip=62.210.252.135; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="edwin+ml-ocaml@etorok.net"; 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.etorok.net) identity=helo; client-ip=62.210.252.135; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="postmaster@mail.etorok.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ABBQBDw41V/4f80j5bgxFUX78UhXQCAgKBP0wBAQEBAQGBC4QjAQEEDCYBDTgBAQEOCxgJEwMPCQMCAQIBRQYNAQcCiC8JuBqFWpEvAQEIAQEBARcBAgSKSIEChQYHhCuHCIUPaocIhFiGeoE6hBCPEoNbJoILAhuBVTsxAYJHAQEB X-IPAS-Result: A0ABBQBDw41V/4f80j5bgxFUX78UhXQCAgKBP0wBAQEBAQGBC4QjAQEEDCYBDTgBAQEOCxgJEwMPCQMCAQIBRQYNAQcCiC8JuBqFWpEvAQEIAQEBARcBAgSKSIEChQYHhCuHCIUPaocIhFiGeoE6hBCPEoNbJoILAhuBVTsxAYJHAQEB X-IronPort-AV: E=Sophos;i="5.13,686,1427752800"; d="scan'208";a="167527539" Received: from mail.etorok.net ([62.210.252.135]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Jun 2015 23:27:50 +0200 Received: by mail.etorok.net (OpenSMTPD) with ESMTP id d235f6cd; Fri, 26 Jun 2015 21:27:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=etorok.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=ml; bh=kpFWwEeqcg8n2h Q6SJ3eRZcqBJ0=; b=r0JJalfcXxyDLRpN2vhLaTvRpwAunncIENeZrbCjOYWWxM rtEhmqJCdEc3NfwzW46KBAMB7sK7szz951setoyQc1FNOWOCCa8zBLEryavhONQo ZOL3M1I+mbr73Bk7Ev3weexsFiO7ov5PbYM0c7iYGryjfmJxp2kjApVJrvjkk= DomainKey-Signature: a=rsa-sha1; c=simple; d=etorok.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=ml; b=V6NiJfQn skftrl7pHXHnpt/HBukWgIn9VwLkW1lyNGvxPJO661WZuLzvJqJOzXFyvGIloC6V S8w5N/hU2BAfJhmsF0XA/e4KA79svT2/5C6NSO+k1R+LizQCvYWKlUvf2m2gIrX1 v0Tyk5ouBzI5PkMNpJgkz8jXqfucpq+UW9Y= Received: by mail.etorok.net (OpenSMTPD) with ESMTPSA id 81fd6190 TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Fri, 26 Jun 2015 21:27:47 +0000 (UTC) Message-ID: <558DC3D2.4040407@etorok.net> Date: Sat, 27 Jun 2015 00:27:46 +0300 From: =?windows-1252?Q?T=F6r=F6k_Edwin?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: "Richard W.M. Jones" CC: caml-list@inria.fr References: <20150623195254.GA32190@annexia.org> <5589C490.2030804@etorok.net> <20150625075858.GC31462@annexia.org> In-Reply-To: <20150625075858.GC31462@annexia.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] inconsistent assumptions over implementation Printf On 06/25/2015 10:58 AM, Richard W.M. Jones wrote: > On Tue, Jun 23, 2015 at 11:41:52PM +0300, Török Edwin wrote: > [...] > > Thanks - I have filed a bug about generating better dependencies: > > https://bugzilla.redhat.com/show_bug.cgi?id=1235561 Do any of the advanced linker features in ocamlopt/ocamlc change the way ocamlobjinfo output should be used by packaging tools? I see that -no-alias-deps adds '--------------------------------' to list of 'implementations imported' sometimes. AFAICT this is properly ignored by the current rpm scripts, but I'm not familiar with how all the other linker features (packs, module aliases, rectypes, ...) work at the .cmx(a) level. Perhaps there should be a 'hello-ocaml-dep' package that contains multiple inter-dependent library sub-packages exercising all these features. For example should -safe-string usage be tracked by the package manager? OCaml itself doesn't complain now when the main application is linked with -safe-string, and some module was compiled without it and ends up modifying the (immutable) strings, and I'm not sure whether that information exists in the .cmi/.cmx (should it?) > >>> Also - could we *please* make the error message more explanatory. >>> Printing out the mismatching MD5 hashes would be a good start. >>> >> >> Yeah, and a -r flag on ocamlobjinfo. > > What would the -r flag do? Starting from a given module recursively print the modules that are part of its interface/implementation hash, perhaps a better name would be --filter-recursive. Of course you'd need to have both the old and new .cmx(a) around, in your case: ocamlobjinfo /usr/lib64/ocaml/stdlib.cmxa --filter-recursive=Printf >hashes1 ocamlobjinfo /path/to/4.02.2+rc1/stdlib.cmxa --filter-recursive=Printf >hashes2 diff -u hashes1 hashes2 In fact such a tool could be built by parsing the output of ocamlobjinfo too: ocamlobjinfo /usr/lib64/ocaml/stdlib.cmxa /path/to/4.02.2+rc1/stdlib.cmxa | ocamlobjdiff --module=Printf Best regards, --Edwin