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 2FCF880208 for ; Sat, 9 Sep 2017 10:36:59 +0200 (CEST) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=kennethadammiller@gmail.com; spf=Pass smtp.mailfrom=kennethadammiller@gmail.com; spf=None smtp.helo=postmaster@mail-lf0-f45.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of kennethadammiller@gmail.com) identity=pra; client-ip=209.85.215.45; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of kennethadammiller@gmail.com designates 209.85.215.45 as permitted sender) identity=mailfrom; client-ip=209.85.215.45; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@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-lf0-f45.google.com) identity=helo; client-ip=209.85.215.45; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="postmaster@mail-lf0-f45.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3APlT3Sh91+mywoP9uRHKM819IXTAuvvDOBiVQ1KB9?= =?us-ascii?q?0OIcTK2v8tzYMVDF4r011RmSAtWdtqoMotGVmp6jcFRI2YyGvnEGfc4EfD4+ou?= =?us-ascii?q?JSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47WLmffqXyq7DMUBg63dU8s?= =?us-ascii?q?fry0ScbuiJG83uW2s4DIbh9TzG62aLZ2aRG3thn5t88MgIIkJLxnjlPovHJOM8?= =?us-ascii?q?tR2WR2LlKSgw20ssau87Zi/ild/fU7+JgTf7/9evEbQLpeASgme0k57cijkBjH?= =?us-ascii?q?SQaVri8fX2MQnwZICgTM6RT7WpP8qAP1s+N83G+ROsigHuN8Yiir86o+EEygsy?= =?us-ascii?q?wALTNstTiP0sE=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AgBGp7NZhi3XVdFcHAEBBAEBCgEBF?= =?us-ascii?q?gEBAQMBAQEJAQEBhQEnB4NwgTaZDoF0kGmHUQqFPgKEBAdCFQEBAQEBAQEBAQE?= =?us-ascii?q?BEgEBAQgLCwgoL4IzBQEeAQWCOwEBAQMBIx0BGx4DAQsGBQsHBioCAiEBAREBB?= =?us-ascii?q?QEODgYBEooYAQMNCKAPQIwLggUFARyDCgWDXgoZJw1XgyUBAQEBBgEBAQEcAgY?= =?us-ascii?q?SgxiCAoYmNYJYhTGCYQWHPIJRlis8izWDV0+EdoITgW6OcIl8gleIRBQFH4EVN?= =?us-ascii?q?YEvMiEkXxqEbw8QDIIDJDaHBoFTAQEB?= X-IPAS-Result: =?us-ascii?q?A0D2AgBGp7NZhi3XVdFcHAEBBAEBCgEBFgEBAQMBAQEJAQE?= =?us-ascii?q?BhQEnB4NwgTaZDoF0kGmHUQqFPgKEBAdCFQEBAQEBAQEBAQEBEgEBAQgLCwgoL?= =?us-ascii?q?4IzBQEeAQWCOwEBAQMBIx0BGx4DAQsGBQsHBioCAiEBAREBBQEODgYBEooYAQM?= =?us-ascii?q?NCKAPQIwLggUFARyDCgWDXgoZJw1XgyUBAQEBBgEBAQEcAgYSgxiCAoYmNYJYh?= =?us-ascii?q?TGCYQWHPIJRlis8izWDV0+EdoITgW6OcIl8gleIRBQFH4EVNYEvMiEkXxqEbw8?= =?us-ascii?q?QDIIDJDaHBoFTAQEB?= X-IronPort-AV: E=Sophos;i="5.42,365,1500933600"; d="scan'208,217";a="236864609" Received: from mail-lf0-f45.google.com ([209.85.215.45]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 09 Sep 2017 10:36:57 +0200 Received: by mail-lf0-f45.google.com with SMTP id q132so9616209lfe.5 for ; Sat, 09 Sep 2017 01:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=zJqcvbDCRqvQuUKd2ZyJD4Xzmt8wM2nFXp+wMoXv3fg=; b=nukgniSUGt+ea6mGhfCC56BqByZ/ooSufXuNJuXUvmvebliAIbFVAYj/1JnPqQTrgv GF4s4k9n+8YgPP0YG3L3fDzqVYNuS1L6R+mzsS4eB2vBX+CgUjwgv/L36Opd6PTXOwJm Svd86dMMTlHOuvIEw0oTVjBfh9nW8vxj5SQ1oKmd0nhvyRAb3eDbI+zRbtuzK7EPSVq/ gi1UYzPHK94WsFF34MzDkOeHTGv++T/najjVnBxrY6uDNk6plBjsko9dzmQ0U74hd25a yMaotq2HFvoVuv4vFx3BZ2o5rC/9NSE6LNpH+k+AAn3C1tucAPFurPxNTcBdNxixc2tD 3TXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=zJqcvbDCRqvQuUKd2ZyJD4Xzmt8wM2nFXp+wMoXv3fg=; b=KuAoqf031kz0iohK8X4Uvm5fYVpWok0syiI5rwS6C4pzypOsL7PodiwMv/N6fe5h86 HNBycSJq5IVOIRXymGq26c30lGwYoRKAHU5hJ/p+fxz6TsCqhvRgt4L47kRHy3m6rGcm 2/T70m+/6rTegbKvgIwsGA81D7WkQsKsbiDInw6k+3FgVATpYOxyhz4zRW3Nhj08OOLz pGmfEUVOYQH0cH5qzgG12mTqv7L73K6g1ic42C591z8sL1uLnib+5RfNyGec54sxyfGq RoyAy3o9kXN6TkvUuNdzAs7+/q+qg9t1vWJ+johWzicTVQbE4RGdfzf24FJxwA5UMtdw OhwA== X-Gm-Message-State: AHPjjUglHdCaNkYkq18i9yEqWZ3BQ5lCq5p5X7FRYtmj+ae0kJ+ebDR0 dTJ6pmYDlBHDCjtvz9w7AzGxiLHCTX0x X-Google-Smtp-Source: AOwi7QBfRfvOoApjP5w/NCNtvHAr3yaj3nOIG8Y0LLqPwv9HmvX4jxkEwwfjy1iHA56i84UTY0K0ly6jHarnPPV+/u8= X-Received: by 10.25.87.79 with SMTP id l76mr2369984lfb.117.1504946216836; Sat, 09 Sep 2017 01:36:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.18 with HTTP; Sat, 9 Sep 2017 01:36:56 -0700 (PDT) In-Reply-To: References: From: Kenneth Adam Miller Date: Sat, 9 Sep 2017 04:36:56 -0400 Message-ID: To: caml users , Ivan Gotovchits Content-Type: multipart/alternative; boundary="001a1141e920a9266d0558bd98a4" Subject: Re: [Caml-list] OSX OCaml ld compile errors --001a1141e920a9266d0558bd98a4 Content-Type: text/plain; charset="UTF-8" Ivan, thanks again for your time and attention. I updated OSX, but I think it was a xcode update. In any case, one of the things that I did try to debug was reinstall opam switch and clear out my environment already, but I'm not 100% positive that I did that in a clean order, so I'll repeat that. Additionally, what I can immediately observe is that a with-c example from oasis builds immediately. If I drop in my .c file (actually a c++ target, with -xc++ in CCOpt) into that project renamed and try to compile it, even with no ml modules, I get the same compile errors. This establishes that a .a file, produced and linked by ocaml with nearly identical build steps, works correctly and can be accepted by ld. ld won't stop ignoring the archive file produced under _build. So among the things that I have done was to make sure that the path environment was consistent regarding the host compiler made visible to ocaml and opam, rebuilding my switch, changing to a different switch to build with, altering my target between x64 to x32 for the underlying linkage to the c++ library I'm trying to use, and manually inspecting the object and archive files for the target architecture. Tonight I'm going to get my homebrew, port and opam packages entirely reinstalled. On Sat, Sep 9, 2017 at 3:19 AM, Ivan Gotovchits wrote: > What did you update? If you've updated OS X I would suggest you to > reinstall macports and to start from a new opam switch. > > Cheers, > Ivan > > On Sep 8, 2017 7:26 PM, "Kenneth Adam Miller" > wrote: > >> Hello, >> >> I'm on OSX, and recently I did an update. I had a working package that >> was building some C/++ code underneath an oasis package successfully all >> the way to where I could run the output binary. Right now I am getting the >> following: >> >> ld: warning: ignoring file src/liblibdai_stubs.a, file was built for >> archive which is not the architecture being linked (x86_64): >> src/liblibdai_stubs.a >> >> And then, literally everything that is output next is just missing >> functions from what ld is ignoring, the liblibdai_stubs.a file: >> >> >> "__wrap_BBPFindClampVardai", referenced from: >> _camlDai___BBPFindClampVar_6660 in libdai.a(dai.o) >> _camlDai__2620 in libdai.a(dai.o) >> >> And so on, for a lot of different functions. I need to get ld to shut up >> and link my application, because I didn't have this problem before the >> update. I've never had this problem on OSX before. The .a file being >> ignored is part of the package that I'm building, and is a result of a >> CSources spec I have in my oasis. >> > --001a1141e920a9266d0558bd98a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ivan, thanks again for your time and attention.

I u= pdated OSX, but I think it was a xcode update. In any case, one of the thin= gs that I did try to debug was reinstall opam switch and clear out my envir= onment already, but I'm not 100% positive that I did that in a clean or= der, so I'll repeat that. Additionally, what I can immediately observe = is that a with-c example from oasis builds immediately. If I drop in my .c = file (actually a c++ target, with -xc++ in CCOpt) into that project renamed= and try to compile it, even with no ml modules, I get the same compile err= ors. This establishes that a .a file, produced and linked by ocaml with nea= rly identical build steps, works correctly and can be accepted by ld. ld wo= n't stop ignoring the archive file produced under _build.

<= /div>
So among the things that I have done was to make sure that the pa= th environment was consistent regarding the host compiler made visible to o= caml and opam, rebuilding my switch, changing to a different switch to buil= d with, altering my target between x64 to x32 for the underlying linkage to= the c++ library I'm trying to use, and manually inspecting the object = and archive files for the target architecture. Tonight I'm going to get= my homebrew, port and opam packages entirely reinstalled.


On Sat,= Sep 9, 2017 at 3:19 AM, Ivan Gotovchits <ivg@ieee.org> wrote:
What did you update? If y= ou've updated OS X I would suggest you to reinstall macports and to sta= rt from a new opam switch.

Che= ers,
Ivan

On Sep 8= , 2017 7:26 PM, "Kenneth Adam Miller" <kennethadammiller@gmail.com&g= t; wrote:
Hello,

I'm on OSX, and recently I did an up= date. I had a working package that was building some C/++ code underneath a= n oasis package successfully all the way to where I could run the output bi= nary. Right now I am getting the following:

ld: warning: ignoring fi= le src/liblibdai_stubs.a, file was built for archive which is not the archi= tecture being linked (x86_64): src/liblibdai_stubs.a

And then, literally everything that is output next is just missing f= unctions from what ld is ignoring, the liblibdai_stubs.a file:


<= div>"__wrap_BBPFindClampVardai", referenced from:
=C2= =A0 =C2=A0 =C2=A0 _camlDai___BBPFindClampVar_6660 in libdai.a(dai.o)
=C2=A0 =C2=A0 =C2=A0 _camlDai__2620 in libdai.a(dai.o)
<= br>
And so on, for a lot of different functions. I need to get ld= to shut up and link my application, because I didn't have this problem= before the update. I've never had this problem on OSX before. The .a f= ile being ignored is part of the package that I'm building, and is a re= sult of a CSources spec I have in my oasis.

--001a1141e920a9266d0558bd98a4--