Re: [Caml-list] OSX OCaml ld compile errors

[Kenneth Adam Miller <kennethadammiller@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3666 bytes --]

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 <ivg@ieee.org> 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.
>>>
>>
>

[-- Attachment #2: Type: text/html, Size: 4914 bytes --]