Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

strange problem building non-pure wheel for apple M1 arm64

166 views
Skip to first unread message

Robin Becker

unread,
Mar 7, 2022, 11:23:18 AM3/7/22
to
I use cibuildwheel to build extensions with a github action. For the macos 11.0 arm64 build I get a strange message from
the load command. So I am looking for assistance to try and figure out what is going wrong.

The cibuild action uses the latest pip 21.2.4 and latest setuptools etc.

I use brew to install freetype version 2.11.1.

The compilations look like this
gcc -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -g -arch
arm64 -DRENDERPM_FT -DLIBART_COMPILATION -DLIBART_VERSION=2.3.21 -Isrc/rl_addons/renderPM
-Isrc/rl_addons/renderPM/libart_lgpl -Isrc/rl_addons/renderPM/gt1 -I/usr/local/include/freetype2
-I/Library/Frameworks/Python.framework/Versions/3.9/include/python3.9 -c src/rl_addons/renderPM/_renderPM.c -o
build/temp.macosx-11.0-arm64-3.9/src/rl_addons/renderPM/_renderPM.o

this is the load command on multiple lines for readability the strange error is

gcc -bundle -undefined dynamic_lookup -g -arch arm64
build/temp.macosx-11.0-arm64-3.9/src/rl_addons/renderPM/_renderPM.o
build/temp.macosx-11.0-arm64-3.9/src/rl_addons/renderPM/gt1/gt1-dict.o
build/temp.macosx-11.0-arm64-3.9/src/rl_addons/renderPM/gt1/gt1-namecontext.o
'''''''other compiled code
build/temp.macosx-11.0-arm64-3.9/src/rl_addons/renderPM/libart_lgpl/art_vpath_dash.o
-L/usr/local/lib
-L/usr/lib
-L/Library/Frameworks/Python.framework/Versions/3.9/lib
-lfreetype -o build/lib.macosx-11.0-arm64-3.9/reportlab/graphics/_renderPM.cpython-39-darwin.so

ld: warning: ignoring file /usr/local/lib/libfreetype.dylib, building for macOS-arm64 but attempting to link with file
built for macOS-x86_64

The above message seems bizarre; everything is compiled for arm64, but gcc doesn't want to use an arm64 dylib.

Can macos experts assist?
--
Robin Becker

Peter Pearson

unread,
Mar 8, 2022, 11:01:58 AM3/8/22
to
On Mon, 7 Mar 2022 16:22:10 +0000, Robin Becker <ro...@reportlab.com> wrote:
[snip]
>
> gcc -bundle -undefined dynamic_lookup -g -arch arm64
[snip]
> -L/usr/local/lib
> -L/usr/lib
> -L/Library/Frameworks/Python.framework/Versions/3.9/lib
> -lfreetype
[snip]
>
> ld: warning: ignoring file /usr/local/lib/libfreetype.dylib, building
> for macOS-arm64 but attempting to link with file
> built for macOS-x86_64
>
> The above message seems bizarre; everything is compiled for arm64, but
> gcc doesn't want to use an arm64 dylib.
>
> Can macos experts assist?

I am not at all expert in MacOS or any of the specifics of this
problem, but I think you want to try to prove that the libfreetype
invoked by "-lfreetype" is built for macOS-arm64 rather than for
macOS-x86-64.

--
To email me, substitute nowhere->runbox, invalid->com.

Christian Gollwitzer

unread,
Mar 8, 2022, 11:09:17 AM3/8/22
to
Am 07.03.22 um 17:22 schrieb Robin Becker:
>
> I use brew to install freetype version 2.11.1.

> gcc -bundle -undefined dynamic_lookup -g -arch arm64
>     build/temp.macosx-11.0-arm64-3.9/src/rl_addons/renderPM/_renderPM.o
>     build/temp.macosx-11.0-arm64-3.9/src/rl_addons/renderPM/gt1/gt1-dict.o
>     build/temp.macosx-11.0-arm64-3.9/src/rl_addons/renderPM/gt1/gt1-namecontext.o
>     '''''''other compiled code
>     build/temp.macosx-11.0-arm64-3.9/src/rl_addons/renderPM/libart_lgpl/art_vpath_dash.o
>     -L/usr/local/lib
>     -L/usr/lib
>     -L/Library/Frameworks/Python.framework/Versions/3.9/lib
>     -lfreetype -o
> build/lib.macosx-11.0-arm64-3.9/reportlab/graphics/_renderPM.cpython-39-darwin.so
>
>
> ld: warning: ignoring file /usr/local/lib/libfreetype.dylib, building
> for macOS-arm64 but attempting to link with file built for macOS-x86_64
>
> The above message seems bizarre; everything is compiled for arm64, but
> gcc doesn't want to use an arm64 dylib.

I would interpret this as: the host is runnig in intel, by doing the
"brew install" it installs the intel version of freetype into
/usr/local/lib/ ; then you cross-compile the python extension for ARM,
but -lfreetype picks up the host version.

On macOS it is not mandatory that all symbols in a .dylib are resolved.
I would guess that the resulting file will not work on M1 macs. YOu can
check by

otool -L /path/toyour.dylib

which libraries are referenced. If you use freetype functions in your C
code and do not see it referenced, then the lib will not work.

Maybe you can install an ARM-version of freetype, or compile it from
source during your build process?

Christian

Robin Becker

unread,
Mar 8, 2022, 12:56:37 PM3/8/22
to
On 08/03/2022 16:08, Christian Gollwitzer wrote:
> Am 07.03.22 um 17:22 schrieb Robin Becker:
>>
>> I use brew to install freetype version 2.11.1.
I find via google that homebrew/apple have split the installation of intel and arm64 into /usr/local and /opt/homebrew
so I must modify the include_dirs & library_dirs in setup.py
--
Robin Becker

0 new messages