From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 0EA3C80208 for ; Sun, 10 Sep 2017 00:20:32 +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-f52.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.52; 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.52 as permitted sender) identity=mailfrom; client-ip=209.85.215.52; 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-f52.google.com) identity=helo; client-ip=209.85.215.52; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="postmaster@mail-lf0-f52.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AWDiKoBNqBfAu9viPR/Ql6mtUPXoX/o7sNwtQ0KIM?= =?us-ascii?q?zox0K/T/rarrMEGX3/hxlliBBdydsK0UzbeO+4nbGkU+or+5+EgYd5JNUxJXwe?= =?us-ascii?q?43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6a8TWO6msZExD7fRdu?= =?us-ascii?q?K/7uUtrZhsGzkuSz4IH7YgNShTP7b6kkfzusqgCElcQQh4Z+Ku4YxhLM6l5Jf+?= =?us-ascii?q?Bb3ys8Jl+VmRvg5s689Ztm8iBUtugJ+MtJUKG8dKM9G+8LRA86Onw4sZW4/SLI?= =?us-ascii?q?ShGCsyMR?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BaAwBXaLRZhjTXVdFcHAEBBAEBCgEBG?= =?us-ascii?q?AEFAQsBhQEnB4NwgTaZDIF0kGqHUQqFPgKEBAdCFQEBAQEBAQEBAQEBEgEBAQg?= =?us-ascii?q?LCwgoL4IzIoJDAQEBAQIBIx0BGx4DAQsGBQsHBioCAiEBAREBBQEODgYTihgBA?= =?us-ascii?q?w0IoWZAjAuCBQUBHIMKBYNWChknDVeDJQEBCAIeAgYSgxmCAoVOWDWCWIUygmE?= =?us-ascii?q?FhzyCUYcbjxA8izWDV0+EdoITgW6OcIl8gleIRBQFH4EVNYEvMiEkXxqEbw8QD?= =?us-ascii?q?IIDJDaJSQEBAQ?= X-IPAS-Result: =?us-ascii?q?A0BaAwBXaLRZhjTXVdFcHAEBBAEBCgEBGAEFAQsBhQEnB4N?= =?us-ascii?q?wgTaZDIF0kGqHUQqFPgKEBAdCFQEBAQEBAQEBAQEBEgEBAQgLCwgoL4IzIoJDA?= =?us-ascii?q?QEBAQIBIx0BGx4DAQsGBQsHBioCAiEBAREBBQEODgYTihgBAw0IoWZAjAuCBQU?= =?us-ascii?q?BHIMKBYNWChknDVeDJQEBCAIeAgYSgxmCAoVOWDWCWIUygmEFhzyCUYcbjxA8i?= =?us-ascii?q?zWDV0+EdoITgW6OcIl8gleIRBQFH4EVNYEvMiEkXxqEbw8QDIIDJDaJSQEBAQ?= X-IronPort-AV: E=Sophos;i="5.42,369,1500933600"; d="scan'208,217";a="236902434" Received: from mail-lf0-f52.google.com ([209.85.215.52]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 10 Sep 2017 00:20:30 +0200 Received: by mail-lf0-f52.google.com with SMTP id m199so11578787lfe.3 for ; Sat, 09 Sep 2017 15:20:30 -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=jSu0FKt4dkSaEMljBFyZC/5IrLjIPRfg7v8b4EEzWaI=; b=Wi4OhBYZUMLcRWxg25/RDFXlvF+n0wBv9asGNHh1Nx3l086EYK9B2PF1nMyn1AuzGm yAZJy/ARbLyOE2hf0Z06yAXIPAq7/c/tfFpyiHy1f/grp06jE98tQ0ntXdVOj3ewcHB3 uJiTJuNO7IsCc7bsE4TFhAvlzusPymhjrViCfDrfcDhZcV0Mjm6MwZzJB8zz1KDe/QGr U+39IVJyya/rpSkc1V1GgkhUQndL0TjQ7iQ8wQp0YgSPhDuKPDuhM+vf3sFc6d+uwpxR Gjju7YhWQmORdVgHAsxnVsPyzhVWsW8OmNYStS6xOwsTJizmcg1vPdgHZUUrSjwMaDhC TM5A== 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=jSu0FKt4dkSaEMljBFyZC/5IrLjIPRfg7v8b4EEzWaI=; b=Y5CSKsK7rIpIqZUHRmzy58+3uru7uZyx3sOde0wfdkepGRf7pAYAM8NYa/kG0RyXFC BbZr8Wmm3AJu8l4kU4/0fIYylEPnrXfntUPfymP0lJuQcLxHnMjogq0PCI2HpOyFWxvL SebKjQSt9H7XVCP/0fKMcDewZsFe5TKhiCqL4YYrdGfZf0mPN7+fXhOSPGy6m+Irw/ju KLT0DvmiVIXvCXMoSayLP/CEAsG1unA5JlFPYzdhUvofbnUVBuhMOVkX/gZiN8Aw5qg1 6dPsfiPkyH02h0TOMr4Ep0BhfpMsQLpd7MPbqJTGuw8CewlLYkb2Zfh20dUHD7epXhVA OXVA== X-Gm-Message-State: AHPjjUiG7+Qi/k33Rl7hvcGbu/5TSyM1S+FsgXzm6tq751WpZ/g1bFVm oGdhHJcCdp1CC+1zkZoLcIjJXy1j6Bqh X-Google-Smtp-Source: AOwi7QBF8AHmf838rp1cHi+JrYxWxS5xt0hnga97JvrtYyoc9vNaZ7lKm+9bYfC8VqOWpkKXtUYvrjqM+BYCstPRR/U= X-Received: by 10.46.71.68 with SMTP id u65mr2630034lja.22.1504995629649; Sat, 09 Sep 2017 15:20:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.18 with HTTP; Sat, 9 Sep 2017 15:20:29 -0700 (PDT) In-Reply-To: References: From: Kenneth Adam Miller Date: Sat, 9 Sep 2017 18:20:29 -0400 Message-ID: To: caml users Content-Type: multipart/alternative; boundary="001a113db70ce4dae00558c919fe" Subject: Re: [Caml-list] OSX OCaml ld compile errors --001a113db70ce4dae00558c919fe Content-Type: text/plain; charset="UTF-8" I found the reason why ld is ignoring it. Specifying the archive file as a library dependency under _oasis causes the linker to skip the target for some reason. Oasis and opam do not give any warning, but somehow expect you to know that you can only put .a files at executable targets in oasis. I had no idea, and this isn't documented to my knowledge, so I thought it would be best if, when the user went to specify my opam package as a dependency they only had to give one name. So far, what has worked was to specify the C++ library archive as an extra dependency in the CCLib of the executable targets. Things tend to work the way you want them to when you are linking against a shared object. I'll release this package soon, and when I do I'll also create an issue with oasis documenting these edge cases that could have some more helpful warnings. On Sat, Sep 9, 2017 at 4:36 AM, Kenneth Adam Miller < kennethadammiller@gmail.com> wrote: > 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" < >> kennethadammiller@gmail.com> 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. >>> >> > --001a113db70ce4dae00558c919fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I found the reason why ld is ignoring it. Specifying the a= rchive file as a library dependency under _oasis causes the linker to skip = the target for some reason. Oasis and opam do not give any warning, but som= ehow expect you to know that you can only put .a files at executable target= s in oasis. I had no idea, and this isn't documented to my knowledge, s= o I thought it would be best if, when the user went to specify my opam pack= age as a dependency they only had to give one name. So far, what has worked= was to specify the C++ library archive as an extra dependency in the CCLib= of the executable targets.=C2=A0

Things tend to work th= e way you want them to when you are linking against a shared object.
<= div>
I'll release this package soon, and when I do I'= ll also create an issue with oasis documenting these edge cases that could = have some more helpful warnings.=C2=A0

On Sat, Sep 9, 2017 at 4:36 AM, Kenneth Ad= am Miller <kennethadammiller@gmail.com> wrote:
=
Ivan, thanks again for your= time and attention.

I updated OSX, but I think it was a xcode updat= e. In any case, one of the things that I did try to debug was reinstall opa= m switch and clear out my environment already, but I'm not 100% positiv= e 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 i= mmediately. If I drop in my .c file (actually a c++ target, with -xc++ in C= COpt) into that project renamed and try to compile it, even with no ml modu= les, I get the same compile errors. This establishes that a .a file, produc= ed and linked by ocaml with nearly identical build steps, works correctly a= nd can be accepted by ld. ld won't stop ignoring the archive file produ= ced under _build.

So among the things that I have do= ne was to make sure that the path environment was consistent regarding the = host compiler made visible to ocaml and opam, rebuilding my switch, changin= g to a different switch to build with, altering my target between x64 to x3= 2 for the underlying linkage to the c++ library I'm trying to use, and = manually inspecting the object and archive files for the target architectur= e. Tonight I'm going to get my homebrew, port and opam packages entirel= y reinstalled.


On Sat, S= ep 9, 2017 at 3:19 AM, Ivan Gotovchits <ivg@ieee.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
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.

Cheer= s,
Ivan

On Sep 8, 2017 7:26 PM, "Kenneth Adam = Miller" <kennethadammiller@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Hello,

I&= #39;m on OSX, and recently I did an update. I had a working package that wa= s 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 foll= owing:

ld: warning: ignoring file src/liblibdai_stubs.a, file was bu= ilt for archive which is not the architecture being linked (x86_64): src/li= blibdai_stubs.a

And then, literally everything= that is output next is just missing functions from what ld is ignoring, th= e liblibdai_stubs.a file:


"__wrap_BBPFindClampVardai&q= uot;, referenced from:
=C2=A0 =C2=A0 =C2=A0 _camlDai___BBPFindCla= mpVar_6660 in libdai.a(dai.o)
=C2=A0 =C2=A0 =C2=A0 _camlDai_= _2620 in libdai.a(dai.o)

And so on, for a lot of d= ifferent functions. I need to get ld to shut up and link my application, be= cause 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 packag= e that I'm building, and is a result of a CSources spec I have in my oa= sis.


--001a113db70ce4dae00558c919fe--