[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190326090225.GA28847@openwall.com>
Date: Tue, 26 Mar 2019 10:02:25 +0100
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Compiler errors on macOS Mojave 10.14.2
Marvin, Erik, all -
On Mon, Mar 25, 2019 at 07:23:26PM +0100, Solar Designer wrote:
> It looks like "ar" is somehow creating archives for a wrong
> architecture. This is puzzling to me because historically "ar" was a
> very simple archiver and technically not necessarily used for static
> libraries (and thus wouldn't need to be architecture-aware), although
> that ended up being its sole use case.
>
> Marvin - do you have any update?
>
> > ar: creating aes.a
> > ar: creating ed25519-donna.a
> > ar: creating secp256k1.a
> > ld: warning: ignoring file aes/aes.a, file was built for archive which is not the architecture being linked (x86_64): aes/aes.a
> > ld: warning: ignoring file ed25519-donna/ed25519-donna.a, file was built for archive which is not the architecture being linked (x86_64): ed25519-donna/ed25519-donna.a
> > ld: warning: ignoring file secp256k1/secp256k1.a, file was built for archive which is not the architecture being linked (x86_64): secp256k1/secp256k1.a
> > Undefined symbols for architecture x86_64:
> > "_ed25519_publickey", referenced from:
I just looked into this some more, specifically doing a Google web
search on "file was built for archive which is not the architecture
being linked" (in quotes) and seeing what other people/projects facing
this issue do. This is probably the most useful answer:
https://github.com/pjreddie/darknet/issues/1350#issuecomment-471237949
> dhalperi commented 16 days ago
>
> I found this was an issue with Homebrew binutils package conflicting
> with XCode. For more info, see
> https://stackoverflow.com/a/43452124/1715495.
>
> `brew unlink binutils && make clean && make` did the trick for me.
The StackOverflow issue referenced from there says:
> A possible cause is using the GNU ar(1)/ranlib(1) instead of the ones
> supplied by the Xcode toolchain. Run which -a ar and which -a ranlib
> to see the what you have in $PATH.
and:
> If you're like me and had /usr/local/bin preceeding /usr/bin in $PATH,
> with the GNU tools in /usr/local/bin and the Xcode ones in /usr/bin,
> you can fix it with:
>
> cd /usr/local/bin
> mv ar gar
> ln -s /usr/bin/ar ar
> mv ranlib granlib
> ln -s /usr/bin/ranlib ranlib
Marvin - can you please try one of these recipes, most likely the first
one, and let us know if it helped? Specifically:
brew unlink binutils
Thanks,
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
