This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: clang: error: linker command failed with exit code 1 (use -v to see invocation) on m1 mac
Type: compile error Stage: resolved
Components: macOS Versions: Python 3.11
process
Status: closed Resolution: third party
Dependencies: Superseder:
Assigned To: Nosy List: Battant, andrei.avk, jaraco, ned.deily, ronaldoussoren
Priority: normal Keywords:

Created on 2022-03-10 16:38 by Battant, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (12)
msg414859 - (view) Author: Battant (Battant) Date: 2022-03-10 16:38
Hello,

Here is my configuration

mac os 12.2.1
mac m1 pro 2021

step to reproduce
1. on mac m1, clone cpython repository main branch
run
./confugure
make
Actual result :
gcc   -fno-semantic-interposition -fprofile-instr-generate -Wl,-stack_size,1000000  -framework CoreFoundation -o python.exe Programs/python.o libpython3.10d.a -ldl   -framework CoreFoundation    
gcc   -fno-semantic-interposition -fprofile-instr-generate -Wl,-stack_size,1000000  -framework CoreFoundation -o Programs/_testembed Programs/_testembed.o libpython3.10d.a -ldl   -framework CoreFoundation    
Undefined symbols for architecture arm64:
  "_libintl_bindtextdomain", referenced from:
Undefined symbols for architecture arm64:
  "_libintl_bindtextdomain", referenced from:
      __locale_bindtextdomain_impl in libpython3.10d.a(_localemodule.o)
      __locale_bindtextdomain_impl in libpython3.10d.a(_localemodule.o)
  "_libintl_dcgettext", referenced from:
  "_libintl_dcgettext", referenced from:
      __locale_dcgettext_impl in libpython3.10d.a(_localemodule.o)
      __locale_dcgettext_impl in libpython3.10d.a(_localemodule.o)
  "_libintl_dgettext", referenced from:
  "_libintl_dgettext", referenced from:
      __locale_dgettext_impl in libpython3.10d.a(_localemodule.o)
      __locale_dgettext_impl in libpython3.10d.a(_localemodule.o)
  "_libintl_gettext", referenced from:
  "_libintl_gettext", referenced from:
      __locale_gettext_impl in libpython3.10d.a(_localemodule.o)
      __locale_gettext_impl in libpython3.10d.a(_localemodule.o)
  "_libintl_setlocale", referenced from:
  "_libintl_setlocale", referenced from:
      __locale_setlocale_impl in libpython3.10d.a(_localemodule.o)
      _locale_decode_monetary in libpython3.10d.a(_localemodule.o)
      __locale_setlocale_impl in libpython3.10d.a(_localemodule.o)
      _locale_decode_monetary in libpython3.10d.a(_localemodule.o)
  "_libintl_textdomain", referenced from:
  "_libintl_textdomain", referenced from:
      __locale_textdomain_impl in libpython3.10d.a(_localemodule.o)
      __locale_textdomain_impl in libpython3.10d.a(_localemodule.o)
ld: symbol(s) not found for architecture arm64
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [python.exe] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: *** [Programs/_testembed] Error 1
make[2]: *** [build_all_generate_profile] Error 2
make[1]: *** [profile-gen-stamp] Error 2
make: *** [profile-run-stamp] Error 2

Could you help me please to fix this issus ?

Best regards

Battant
msg414873 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2022-03-10 17:32
Without more details, this is only a guess but the messages seem to indicate that your build is detecting an installed version of the GNU gettext library, which is optional for Python builds and is not provided by default on macOS, and most likely that version is an Intel-only build of the package and its libintl shared library. Check whether you have an outdated version of gettext and libintl*.dylib installed somewhere, perhaps in /usr/local/, possibly via a third-party package manager like Homebrew or MacPorts, and either remove it or update it with a arm64 (or universal2 fat) build.
msg415183 - (view) Author: Andrei Kulakov (andrei.avk) * (Python triager) Date: 2022-03-14 20:14
I've had the same issue and fixed it with:

  brew remove --ignore-dependencies gettext

@Ned thanks for help!
msg415831 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2022-03-22 22:26
I ran into this same issue. I notice that gettext is a dependency of git, so a common dependency when developing. Is there perhaps a way that CPython could be made to ignore gettext on macos Silicon or to detect an incompatible platform and thus ignore it?
msg415832 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2022-03-22 22:28
There shouldn't be a problem as long as gettext is properly installed on an M1 Mac, i.e. with an arm64 arch or a universal build that includes arm64.
msg415835 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2022-03-22 22:36
Well, I'm using a mac with gettext installed as part of `brew install git` with homebrew installed using the standard procedure.

Only after running `brew remove --ignore-dependencies gettext` and re-running configure/make did the command build, but doing so also broke features of git (I noticed that the branch name disappeared from my shell). I was able to reinstall git and gettext, but then configure/make failed.

Do you have any advice on how to "properly install" gettext using homebrew on an M1 mac?
msg415836 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2022-03-22 22:44
This also applies to any other third-party library that a cpython build may link to, like the OpenSSL libs. Some legacy tools that depend on them may work in Rosetta 2 Intel-64 emulation mode on an Apple Silicon Mac but eventually that will go away so it is important to move away from any inadvertent Rosetta dependencies.

I don't use Homebrew myself but a quick web search comes up with a number of hits on how to proceed. It looks like the general idea is to save your list of installed brew packages, reinstall the base homebrew to install Apple Silicon native versions, and then reinstall the top-level packages you had and want and you should be good to go from there on.
msg415840 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2022-03-22 23:33
SG. Thanks for the advice. I'll dive in and experiment and report back when I have progress.
msg415871 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2022-03-23 13:22
I did [this search](https://www.google.com/search?q=gittext+homebrew+"ld%3A+symbol(s)+not+found+for+architecture+arm64"), which surfaced a few related results.

[This article](https://lifesaver.codes/answer/pyenv-arm64-builds-confused-by-x86-64-libintl-in-usr-local-1877) seemed promising, but the symptoms there are different than mine. I don't have any gettext libs showing up in /usr/local (only in /opt/homebrew as expected).

I noticed [this comment](https://github.com/pyenv/pyenv/issues/1877#issuecomment-976583556) reports the same issue I have, but no solution is present.

I saw a suggestion to [set FLAGS](https://github.com/pyenv/pyenv/issues/1877#issuecomment-836115970), but I do that [as a matter of course](https://github.com/jaraco/jaraco.develop/blob/d3e524362ba15f87790f4c6279b1f92c06901387/jaraco/develop/macos-build-python.py#L38-L42).

I don't have an x86 install of homebrew. This machine is less than a month old and has had ARM-based homebrew installed from the beginning.

I'll keep investigating.
msg415873 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2022-03-23 13:38
As suggested, I uninstalled and reinstalled everything in homebrew:

$ brew list | xargs brew remove
$ brew install python@3.10 python-launcher python@3.9 python@3.8 gh git

Even after following those steps and setting LDFLAGS and CPPFLAGS to point to `brew --prefix`, the errors continue when running `./configure; make` in a clean checkout.
msg415874 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2022-03-23 13:44
Aha. If I configure/make without LDFLAGS or CPPFLAGS set, compilation works. Then I noticed for `LDFLAGS`, some users were using `-L`. I thought it was slightly odd that my recipe was using `-I` for both flags. How is it that [this mistake](https://github.com/jaraco/jaraco.develop/commit/6469c7a61e7349b93f191df38eed6cd020dd79be) hasn't caused me any grief until M1 build?  No matter - correcting for that mistake and passing the correct LDFLAGS flag (-L) corrects for the issue.
msg415875 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2022-03-23 13:46
It's possible my bad experience may have been avoided through issue35905.
History
Date User Action Args
2022-04-11 14:59:57adminsetgithub: 91131
2022-03-23 13:46:53jaracosetmessages: + msg415875
2022-03-23 13:44:01jaracosetstatus: open -> closed

messages: + msg415874
2022-03-23 13:38:17jaracosetmessages: + msg415873
2022-03-23 13:22:54jaracosetmessages: + msg415871
2022-03-22 23:33:56jaracosetstatus: closed -> open

messages: + msg415840
2022-03-22 22:44:09ned.deilysetstatus: open -> closed

messages: + msg415836
2022-03-22 22:36:54jaracosetmessages: + msg415835
2022-03-22 22:28:56ned.deilysetmessages: + msg415832
2022-03-22 22:26:12jaracosetstatus: closed -> open
nosy: + jaraco
messages: + msg415831

2022-03-14 20:24:23ned.deilysetstatus: open -> closed
resolution: third party
stage: resolved
2022-03-14 20:14:58andrei.avksetnosy: + andrei.avk
messages: + msg415183
2022-03-10 17:32:07ned.deilysetmessages: + msg414873
2022-03-10 16:38:01Battantcreate