pyenv arm64 builds confused by x86_64 libintl in /usr/local

[mikepqr]

I'm trying to follow homebrew's advice and supported workflow to configure a system with both arm64 and x86_64 brew packages, i.e. put an arm64 brew in /opt/homebrew and an x86 brew in /usr/local.

Both have a copy of the gettext package (which is a dependency of ... well ... pretty much everything).

The arm64 brew has pyenv. pyenv install 3.9.4 fails with:

ar rcs libpython3.9.a Modules/getbuildinfo.o Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/token.o  Parser/pegen/pegen.o Parser/pegen/parse.o Parser/pegen/parse_string.o Parser/pegen/peg_api.o Parser/myreadline.o Parser/parsetok.o Parser/tokenizer.o Objects/abstract.o Objects/accu.o Objects/boolobject.o Objects/bytes_methods.o Objects/bytearrayobject.o Objects/bytesobject.o Objects/call.o Objects/capsule.o Objects/cellobject.o Objects/classobject.o Objects/codeobject.o Objects/complexobject.o Objects/descrobject.o Objects/enumobject.o Objects/exceptions.o Objects/genericaliasobject.o Objects/genobject.o Objects/fileobject.o Objects/floatobject.o Objects/frameobject.o Objects/funcobject.o Objects/interpreteridobject.o Objects/iterobject.o Objects/listobject.o Objects/longobject.o Objects/dictobject.o Objects/odictobject.o Objects/memoryobject.o Objects/methodobject.o Objects/moduleobject.o Objects/namespaceobject.o Objects/object.o Objects/obmalloc.o Objects/picklebufobject.o Objects/rangeobject.o Objects/setobject.o Objects/sliceobject.o Objects/structseq.o Objects/tupleobject.o Objects/typeobject.o Objects/unicodeobject.o Objects/unicodectype.o Objects/weakrefobject.o Python/_warnings.o Python/Python-ast.o Python/asdl.o Python/ast.o Python/ast_opt.o Python/ast_unparse.o Python/bltinmodule.o Python/ceval.o Python/codecs.o Python/compile.o Python/context.o Python/dynamic_annotations.o Python/errors.o Python/frozenmain.o Python/future.o Python/getargs.o Python/getcompiler.o Python/getcopyright.o Python/getplatform.o Python/getversion.o Python/graminit.o Python/hamt.o Python/hashtable.o Python/import.o Python/importdl.o Python/initconfig.o Python/marshal.o Python/modsupport.o Python/mysnprintf.o Python/mystrtoul.o Python/pathconfig.o Python/peephole.o Python/preconfig.o Python/pyarena.o Python/pyctype.o Python/pyfpe.o Python/pyhash.o Python/pylifecycle.o Python/pymath.o Python/pystate.o Python/pythonrun.o Python/pytime.o Python/bootstrap_hash.o Python/structmember.o Python/symtable.o Python/sysmodule.o Python/thread.o Python/traceback.o Python/getopt.o Python/pystrcmp.o Python/pystrtod.o Python/pystrhex.o Python/dtoa.o Python/formatter_unicode.o Python/fileutils.o Python/dynload_shlib.o    Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o Modules/posixmodule.o  Modules/errnomodule.o  Modules/pwdmodule.o  Modules/_sre.o  Modules/_codecsmodule.o  Modules/_weakref.o  Modules/_functoolsmodule.o  Modules/_operator.o  Modules/_collectionsmodule.o  Modules/_abc.o  Modules/itertoolsmodule.o  Modules/atexitmodule.o  Modules/signalmodule.o  Modules/_stat.o  Modules/timemodule.o  Modules/_threadmodule.o  Modules/_localemodule.o  Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modules/bytesio.o Modules/bufferedio.o Modules/textio.o Modules/stringio.o  Modules/faulthandler.o  Modules/_tracemalloc.o  Modules/_peg_parser.o  Modules/symtablemodule.o  Modules/xxsubtype.o Python/frozen.o
clang -L/opt/homebrew/opt/readline/lib -L/opt/homebrew/opt/readline/lib -L/Users/mike/.pyenv/versions/3.9.4/lib  -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -L/opt/homebrew/opt/readline/lib -L/opt/homebrew/opt/readline/lib -L/Users/mike/.pyenv/versions/3.9.4/lib  -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib   -Wl,-stack_size,1000000  -framework CoreFoundation -o python.exe Programs/python.o libpython3.9.a -ldl   -framework CoreFoundation    
clang -L/opt/homebrew/opt/readline/lib -L/opt/homebrew/opt/readline/lib -L/Users/mike/.pyenv/versions/3.9.4/lib  -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -L/opt/homebrew/opt/readline/lib -L/opt/homebrew/opt/readline/lib -L/Users/mike/.pyenv/versions/3.9.4/lib  -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib   -Wl,-stack_size,1000000  -framework CoreFoundation -o Programs/_testembed Programs/_testembed.o libpython3.9.a -ldl   -framework CoreFoundation    
Undefined symbols for architecture arm64:
Undefined symbols for architecture arm64:
  "_libintl_bindtextdomain", referenced from:
  "_libintl_bindtextdomain", referenced from:
      _PyIntl_bindtextdomain in libpython3.9.a(_localemodule.o)
      _PyIntl_bindtextdomain in libpython3.9.a(_localemodule.o)
  "_libintl_dcgettext", referenced from:
  "_libintl_dcgettext", referenced from:
      _PyIntl_dcgettext in libpython3.9.a(_localemodule.o)
      _PyIntl_dcgettext in libpython3.9.a(_localemodule.o)
  "_libintl_dgettext", referenced from:
  "_libintl_dgettext", referenced from:
      _PyIntl_dgettext in libpython3.9.a(_localemodule.o)
      _PyIntl_dgettext in libpython3.9.a(_localemodule.o)
  "_libintl_gettext", referenced from:
  "_libintl_gettext", referenced from:
      _PyIntl_gettext in libpython3.9.a(_localemodule.o)
      _PyIntl_gettext in libpython3.9.a(_localemodule.o)
  "_libintl_setlocale", referenced from:
  "_libintl_setlocale", referenced from:
      _PyLocale_setlocale in libpython3.9.a(_localemodule.o)
      _PyLocale_localeconv in libpython3.9.a(_localemodule.o)
      _PyLocale_setlocale in libpython3.9.a(_localemodule.o)
      _PyLocale_localeconv in libpython3.9.a(_localemodule.o)
  "_libintl_textdomain", referenced from:
  "_libintl_textdomain", referenced from:
      _PyIntl_textdomain in libpython3.9.a(_localemodule.o)
      _PyIntl_textdomain in libpython3.9.a(_localemodule.o)
ld: symbol(s) not found for architecture arm64
ld: symbol(s) not found for architecture arm64
clang: clang: error: error: linker command failed with exit code 1 (use -v to see invocation)

But if I move/rename these three files in /usr/local it works fine (based on a clue in this comment:

/usr/local/lib/libgettextlib.dylib
/usr/local/lib/libintl.dylib
/usr/local/include/libintl.h

I don't see any mention of /usr/local in the output of pyenv install. It appears to have correctly set up its paths. But these files in /usr/local determine whether it works or not.

brew doctor does warn me that these files are likely to cause problems:

Warning: gettext files detected at a system prefix.
These files can cause compilation and link failures, especially if they
are compiled with improper architectures. Consider removing these files:
  /opt/homebrew/lib/libgettextlib.dylib
  /opt/homebrew/lib/libintl.dylib
  /opt/homebrew/include/libintl.h
  /usr/local/lib/libgettextlib.dylib
  /usr/local/lib/libintl.dylib
  /usr/local/include/libintl.h

but I was under the impression that pyenv goes to lengths to avoid getting confused by situations like this. There are copies of several libraries pyenv links in my /usr/local and /opt/homebrew, but pyenv gets the (correct) /opt/homebrew library every time, with the exception of these gettext libraries/headers.

Can anyone help me understand what's happening? Is this a situation pyenv could handle better? Or is it a brew problem? I assume simply deleting those files is not a good long term solution?

[native-api]

Caveats section in brew info <formula> output says how to make compilers find a library that is keg-only.

[mikepqr]

Thanks but brew info gettext has no caveats section.

[native-api]

Thanks but brew info gettext has no caveats section.

So it's not keg-only -- and the build still can't find it. That's bad -- normally, programs form Homebrew are supposed to see non-keg-only libs out of the box.
I don't have Apple hardware so can't diagnose this myself.

Apparently, you need to somehow make the build aware of the necessary library at where it is.
I don't know if Homebrew is supposed to be doing this. I don't know how a program from Homebrew is supposed to know which Homebrew installation is should be using.
Since this is a Homebrew-related issue and ARM64 support in Homebrew is currently in active development, I suggest you to get this information at Homebrew forums.

Currently, I don't know what Pyenv can do here -- and more importantly, if it's even supposed to be doing anything or it's something else's job.

[native-api]

#1853 suggests that arch can be used to switch between ARM and x64 ecosystems.

Logically speaking. if you have two Homebrew installations for different architectures (thus different software ecosystems), you should have a separate Pyenv installation in each of them, and there should be some facility to choose which of these Homebrew installations you want to use -- so that you get the pyenv instance that corresponds to it.

[mikepqr]

Logically speaking. if you have two Homebrew installations for different architectures (thus different software ecosystems), you should have a separate Pyenv installation in each of them, and there should be some facility to choose which of these Homebrew installations you want to use -- so that you get the pyenv instance that corresponds to it.

I don't need or want i386 builds of Python, so I don't need or want i386 pyenv. My problem is that I'm trying to do an arm build using pyenv configured to use arm (the only pyenv on my system), and it's trying to link the wrong copy of a library.

Apparently, you need to somehow make the build aware of the necessary library at where it is.

The problem is not that pyenv can't find this library. It's that I have two copies and it's finding the wrong instance of the library. This does not appear to happen for any other library that pyenv links, even though I have two copies of those (openssl, etc.)

I also don't know if this is pyenv's responsibility, but it appears to know how to deal with this situation for other libraries, and is only struggling with gettext.

[native-api]

ld: symbol(s) not found for architecture arm64

Wait a second... That's ld and not dyld.

Do you by any chance have libintl.a under /usr/local/lib but not under /opt/homebrew/lib?

It's also strange that /opt/homebrew/lib is not in library search path.

I suspect that you're mixing up the two Homebrew installations and your Pyenv probably belongs to the x64 one.

---

Please

• Use steps from https://stackoverflow.com/questions/64951024/how-can-i-run-two-isolated-installations-of-homebrew to isolate your two Homebrew installlations from each other
• provide the output of these commands:

clang -arch arm64 -E -x c - -v < /dev/null
clang -arch arm64 -Xlinker -v
which -a pyenv brew
pyenv root

• upgrade Pyenv to the latest head
• provide full debug output of a failing Pyenv invocation with -v as required by the issue template (otherwise, I don't have the info to diagnose this any further)

[mikepqr]

First I want to say thank you very much for your patience on this issue! I'm aware I'm on the bleeding edge here, and doing something slightly unusual, and I really appreciate your taking the time to help me debug an issue that is quite likely not even a pyenv problem!

Do you by any chance have libintl.a under /usr/local/lib but not under /opt/homebrew/lib?

No.

$ ls /usr/local/lib/libint*
ls: cannot access '/usr/local/lib/libint*': No such file or directory
$ ls /opt/homebrew/lib/libint*
/opt/homebrew/lib/libintl.8.dylib@  /opt/homebrew/lib/libintl.a@  /opt/homebrew/lib/libintl.dylib@

It's also strange that /opt/homebrew/lib is not in library search path.

Indeed! :-)

I suspect that you're mixing up the two Homebrew installations and your Pyenv probably belongs to the x64 one.

I don't have an i386 copy of pyenv.

provide the output of these commands:

$ clang -arch arm64 -E -x c - -v < /dev/null | pbcopy
Apple clang version 12.0.5 (clang-1205.0.22.9)
Target: aarch64-apple-darwin20.4.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
 "/Library/Developer/CommandLineTools/usr/bin/clang" -cc1 -triple arm64-apple-macosx11.0.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -Werror=implicit-function-declaration -E -disable-free -disable-llvm-verifier -discard-value-names -main-file-name - -mrelocation-model pic -pic-level 2 -mframe-pointer=non-leaf -fno-strict-return -fno-rounding-math -munwind-tables -target-sdk-version=11.3 -fvisibility-inlines-hidden-static-local-var -target-cpu apple-a12 -target-feature +v8.3a -target-feature +fp-armv8 -target-feature +neon -target-feature +crc -target-feature +crypto -target-feature +fullfp16 -target-feature +ras -target-feature +lse -target-feature +rdm -target-feature +rcpc -target-feature +zcm -target-feature +zcz -target-feature +sha2 -target-feature +aes -target-abi darwinpcs -fallow-half-arguments-and-returns -debugger-tuning=lldb -target-linker-version 650.9 -v -resource-dir /Library/Developer/CommandLineTools/usr/lib/clang/12.0.5 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -I/usr/local/include -internal-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include -internal-isystem /Library/Developer/CommandLineTools/usr/lib/clang/12.0.5/include -internal-externc-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -internal-externc-isystem /Library/Developer/CommandLineTools/usr/include -Wno-reorder-init-list -Wno-implicit-int-float-conversion -Wno-c99-designator -Wno-final-dtor-non-final-class -Wno-extra-semi-stmt -Wno-misleading-indentation -Wno-quoted-include-in-framework-header -Wno-implicit-fallthrough -Wno-enum-enum-conversion -Wno-enum-float-conversion -Wno-elaborated-enum-base -fdebug-compilation-dir /Users/mike/p/study/interviews -ferror-limit 19 -stack-protector 1 -fstack-check -mdarwin-stkchk-strong-link -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fmax-type-align=16 -fcommon -fcolor-diagnostics -clang-vendor-feature=+disableNonDependentMemberExprInCurrentInstantiation -fno-odr-hash-protocols -mllvm -disable-aligned-alloc-awareness=1 -o - -x c -
clang -cc1 version 12.0.5 (clang-1205.0.22.9) default target arm64-apple-darwin20.4.0
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /Library/Developer/CommandLineTools/usr/lib/clang/12.0.5/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
 /Library/Developer/CommandLineTools/usr/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.

$ clang -arch arm64 -Xlinker -v
@(#)PROGRAM:ld  PROJECT:ld64-650.9
BUILD 00:19:34 Mar 17 2021
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
Library search paths:
	/usr/local/lib
	/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
Framework search paths:
	/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/
Undefined symbols for architecture arm64:
  "_main", referenced from:
     implicit entry/start for main executable
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

(That looks weird to me!)

$ which -a pyenv brew
/opt/homebrew/bin/pyenv
/opt/homebrew/bin/brew
/usr/local/bin/brew

$ pyenv root
/Users/mike/.pyenv

I'll post the build logs in the next comment.

[mikepqr]

The logs were too long to post as comments, so here they are. Hope that's OK!

[native-api]

Okay, -L/opt/homebrew/lib/ missing from linker flags does look like the cause.
I also see that -I/opt/homebrew/include is not in compiler flags (that doesn't cause an error -- perhaps because all the looked-for header files happen to also be present in the x64 Homebrew; this is still problematic).

Since it's not the default, unlike /usr/local/lib, ARM64 Homebrew has to be adding it somehow for invocations done from its environment -- or have some other mechanism for passing it to builds.

I didn't find any information on this and asked it at Homebrew/discussions#1423 .

---

For now, this looks like some misconfiguration on your system. But if there actually is some mechanism provided by ARM64 Homebrew that 3rd-party programs must engage by hand, that would be Pyenv's issue.

As a workaround, you can export LDFLAGS="-L/opt/homebrew/lib"; export CPPFLAGS="-I/opt/homebrew/include" in some startup file.

---

I suggest you to follow that ticket to diagnose this issue further and find out what needs to be done and report any findings here.

[native-api]

@mikepqr Did the workaround work?

[mikepqr]

Sorry for the delay. I will try to tomorrow.

[mikepqr]

Confirmed.

Explicitly setting export LDFLAGS="-L/opt/homebrew/lib"; export CPPFLAGS="-I/opt/homebrew/include" before running pyenv install 3.9.3 allows the arm64 install to succeed using the arm64 libraries/headers.

However, simply removing the i386 homebrew installation in /usr/local (without explicitly setting any FLAGS!) also allows the installation to succeed. I just tested that too.

It seems like the python build can find the libgettext libraries/headers in /opt/homebrew/. The problem is if those libraries also exist in /usr/local then the build (wrongly) uses those instead. Setting FLAGS explicitly prevents that.

[heyalexchoi]

The flags helped me as well. Had to do one more step:
brew install gettext . I think b/c I have it installed from old brew, but did not have it installed in new.
For anyone else following this trail after me.

[bbrown1867]

I'm having this same issue on an M1 MacBook. Unlike the original author, I do not even have x86 emulated Homebrew installed into /usr/local, I simply have the "new" ARM Homebrew in /opt/homebrew. I have gettext installed:

% brew info gettext
gettext: stable 0.21 (bottled)
GNU internationalization (i18n) and localization (l10n) library
https://www.gnu.org/software/gettext/
/opt/homebrew/Cellar/gettext/0.21 (1,953 files, 20.8MB) *
  Poured from bottle on 2021-11-02 at 13:38:08
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/gettext.rb
License: GPL-3.0-or-later

I try to install Python 3.9.7 "universal" binary:

% export PYTHON_CONFIGURE_OPTS="--enable-universalsdk --with-universal-archs=universal2"
% pyenv install 3.9.7
python-build: use openssl@1.1 from homebrew
python-build: use readline from homebrew
Downloading Python-3.9.7.tar.xz...
-> https://www.python.org/ftp/python/3.9.7/Python-3.9.7.tar.xz
Installing Python-3.9.7...
python-build: use readline from homebrew
python-build: use zlib from xcode sdk

BUILD FAILED (OS X 11.6.1 using python-build 20180424)

Inspect or clean up the working tree at /var/folders/dc/bwq9nb493_z5xdkpbttjc0rw0000gn/T/python-build.20211123090327.12673
Results logged to /var/folders/dc/bwq9nb493_z5xdkpbttjc0rw0000gn/T/python-build.20211123090327.12673.log

Last 10 log lines:
  "_libintl_textdomain", referenced from:
      _PyIntl_textdomain in libpython3.9.a(_localemodule.o)
      _PyIntl_textdomain in libpython3.9.a(_localemodule.o)
ld: symbol(s) not found for architecture arm64
ld: symbol(s) not found for architecture arm64
clang: clang: error: linker command failed with exit code 1 (use -v to see invocation)
error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [python.exe] Error 1
make: *** Waiting for unfinished jobs....
make: *** [Programs/_testembed] Error 1

Does pyenv support universal Python distributions? This is pyenv 2.2.0 install from Homebrew.

[mikegrima]

Building universal2 binaries seems to fail with openssl issues. I've tried many things but don't know how to move forward:

user@computer client % export PYTHON_CONFIGURE_OPTS="--enable-framework --enable-universalsdk --with-universal-archs=universal2" 
user@computer client % LDFLAGS="-L/opt/homebrew/lib" CPPFLAGS="-I/opt/homebrew/include" pyenv install 3.9.11

python-build: use openssl@1.1 from homebrew
python-build: use readline from homebrew
Downloading Python-3.9.11.tar.xz...
-> https://www.python.org/ftp/python/3.9.11/Python-3.9.11.tar.xz
Installing Python-3.9.11...
python-build: use tcl-tk from homebrew
python-build: use readline from homebrew
python-build: use zlib from xcode sdk
ERROR: The Python ssl extension was not compiled. Missing the OpenSSL lib?

EDIT: I eventually figured this out. The culprit is related to openssl being installed by homebrew not being a universal2 binary. You will literally need to download the openssl code, manually compile it for intel and arm, and then run the lipo command to make a fat binary. Once you do that you need to provide that universal2 binary in the LDFLAGS. This page has more details on how to do that: https://blog.andrewmadsen.com/2020/06/22/building-openssl-for.html

[amolgawai]

Documenting my situation for anyone in the similar situation as it was frustrating for many days to struggle with the same symptoms but nothing seemed to work.

My Situation
I had an intel Mac and had setup homebrew and was using it for many days. When I migrated to an M1 Mac, I used the migration assistance (probably the start of the problems) which copied over everything for the homebrew. This seemed logical as everything was working fine after I installed Rosetta 2 (Which was required for some other apps).
As I was migrating slowly towards apple silicon supported app, I gave it a go with homebrew. The new installation seemed to work and I thought I have apple silicon version of most of the apps. Then I tried to get my workflow with pyenv and everything went south. As I searched for the symptoms, it seemed that this was indeed a problem. I tried all the solutions in various discussions but nothing seemed to work.
Eventually I landed on this issue which had the exact same symptoms as I had. Even after updating pyenv and trying the solutions here, it seemed it didn't resolve my problems. Then I checked for homebrew paths and found that the old hombrew things were still there in /usr/local/Cellar. When I moved/deleted this folder, pyenv started to work again. Of course, I need to reinstall some tools and apps for the arch64, but that was my intention anyway.
So for anyone who is having same symptoms but nothing works, remove /usr/local/Cellar...

[jonahclarsen]

I've been struggling with this for hours now, gone through many bugs and tried every solution proposed. Could someone please just share their pre-compiled .dylib files? Specifically I just need _core and _imgcodecs. Would be greatly appreciated.

Edit: I got it working by just installing homebrew and brew install opencv'ing, then using the libraries that showed up in /opt/homebrew/Cellar/opencv/4.5.5_2/lib.

[jollyboss123]

for M1 Mac, can try arch -arm64 pyenv install 3.9.13 to specifically install under ARM

[jeugregg]

Documenting my situation for anyone in the similar situation as it was frustrating for many days to struggle with the same symptoms but nothing seemed to work.

My Situation I had an intel Mac and had setup homebrew and was using it for many days. When I migrated to an M1 Mac, I used the migration assistance (probably the start of the problems) which copied over everything for the homebrew. This seemed logical as everything was working fine after I installed Rosetta 2 (Which was required for some other apps). As I was migrating slowly towards apple silicon supported app, I gave it a go with homebrew. The new installation seemed to work and I thought I have apple silicon version of most of the apps. Then I tried to get my workflow with pyenv and everything went south. As I searched for the symptoms, it seemed that this was indeed a problem. I tried all the solutions in various discussions but nothing seemed to work. Eventually I landed on this issue which had the exact same symptoms as I had. Even after updating pyenv and trying the solutions here, it seemed it didn't resolve my problems. Then I checked for homebrew paths and found that the old hombrew things were still there in /usr/local/Cellar. When I moved/deleted this folder, pyenv started to work again. Of course, I need to reinstall some tools and apps for the arch64, but that was my intention anyway. So for anyone who is having same symptoms but nothing works, remove /usr/local/Cellar...

I was in the same situation.
To be able to install python, I have only removed gettext, openssl, readline, tcl-tk from /usr/local/Cellar.
It depends of each cases. Maybe better to remove all...
thanks.

[Kryan90]

I was having similar issues and ended up fixing it like this:

AR=/usr/bin/ar pyenv install 3.10.3

Looks like it has something to do with having binutils from homebrew installed
#1245

[elitwilliams]

To synthesize above info with my exact error code and the solution:

Goal - install python 3.11.0rc2 or 3.10.7 (or other versions) via e.g. pyenv install 3.11.0rc2

Error -

Last 10 log lines:
  "_libintl_setlocale", referenced from:
      __locale_setlocale in _localemodule.o
      __locale_localeconv in _localemodule.o
  "_libintl_textdomain", referenced from:
      __locale_textdomain in _localemodule.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Programs/_freeze_module] Error 1
make: *** Waiting for unfinished jobs....

Cause - I used Migration Assistant to migrate to M1 from non-M1 Mac. Some non-compatible stuff in /usr/local/Cellar that worked on the old Mac wasn't compatible with the new M1 architecture.

Solution - from @jeugregg

I was in the same situation. To be able to install python, I have only removed gettext, openssl, readline, tcl-tk from /usr/local/Cellar. It depends of each cases. Maybe better to remove all... thanks.

1. In Finder, press Command + Shift + G
2. Paste "/usr/local/Cellar" and press Return
3. Inside the Cellar directory, Delete the following directories: gettext, openssl, readline, tcl-tk
4. Try pyenv install 3.11.0rc2 again at command line (or whatever version you want).

This worked for me!