Why does MoarVM complain about "built for archive which is not the architecture being linked" on Mac OS X?

2
votes

I'm trying to build Moar from the latest on GitHub and the download on MoarVM.org. I keep getting an error about third-party libraries:

ld: warning: ld: warning: ld: warning: ignoring file 3rdparty/libatomic_ops/src/libatomic_ops.a, file was built for archive which is not the architecture being linked (x86_64): 3rdparty/libatomic_ops/src/libatomic_ops.aignoring file 3rdparty/tinymt/libtinymt.a, file was built for archive which is not the architecture being linked (x86_64): 3rdparty/tinymt/libtinymt.aignoring file 3rdparty/sha1/libsha1.a, file was built for archive which is not the architecture being linked (x86_64): 3rdparty/sha1/libsha1.a

This is similar to OSX : File was built for archive which is not the architecture being linked (i386) (and many other questions with insufficient answers). I know that something is building these for the wrong architecture already, so please skip providing that answer.

I've cleaned the directories, deleted everything and started over, told Configure.pl that I'm running on Darwin, and the various other things a user should know to do. I downloaded the tarball from MoarVM.org, which should be the 2105.12 tag in the repo. I run into the same issue with rakudobrew.

Let me know what you'd like to know about my system; it's a basic Mac OS X setup.

I've also filed this as MoarVM issue 334, but it looks like the issue queue doesn't get a lot of love.

1
macosmoarvm

1 Answers

0
votes

From my comment in the MoarVM issue.

I think Sinan and I have figured this out (mostly Sinan though).

When I run configure, it recognizes darwin and selects clang as the compiler. AR is set to merely ar, but that first finds the gnu version in my path instead of the one that goes with clang. When we change the search path around to the first ar is Apple's, everything works.

However, trying Configure.pl --toolchain gnu still chose clang instead of gcc. I don't particularly care which one it uses (at least right now) as long as the other tools come from the right set. I know that I can individually set the paths with args to Configure.pl, but I wouldn't expect to have to do that. I bet most people don't even know what ar is or why they'd set one over the other.

I don't have any advice on this. My problem has a solution, but the Configure could be smarter about this. You can close this issue (maybe opening a fresh one for more smartness).