Tinkering Problems when Compiling on Apple Silicon

[Maxwell Leo]

Dear Das U-Boot Developers:

I recently tried to compile the OpenWRT system on a Mac with Apple Silicon, but encountered problems related to U-Boot.

The problem is that the compiler is not adding system Python3 library by default when compiling the PyModule in some libs, pylibfdt, for example. In the Makefile of pylibfdt, the line “$(call if_changed,pymod)”  invokes the pymod_cmd defined in the Makefile, and it further invokes the gcc command as below:

/Volumes/Develop/openwrt/staging_dir/host/bin/gcc -shared -L/Volumes/Develop/openwrt/staging_dir/host/lib -L/Volumes/Develop/openwrt/staging_dir/hostpkg/lib -L/Volumes/Develop/openwrt/staging_dir/target-aarch64_generic_musl/host/lib -O2 -I/Volumes/Develop/openwrt/staging_dir/host/include -I/Volumes/Develop/openwrt/staging_dir/hostpkg/include -I/Volumes/Develop/openwrt/staging_dir/target-aarch64_generic_musl/host/include -I/Volumes/Develop/openwrt/staging_dir/host/include -I/Volumes/Develop/openwrt/staging_dir/hostpkg/include -I/Volumes/Develop/openwrt/staging_dir/target-aarch64_generic_musl/host/include -std=gnu11 -I/Volumes/Develop/openwrt/build_dir/target-aarch64_generic_musl/u-boot-nanopi-r2s-rk3328/u-boot-2024.01/scripts/dtc/libfdt build/temp.macosx-14.0-arm64-cpython-312/Volumes/Develop/openwrt/build_dir/target-aarch64_generic_musl/u-boot-nanopi-r2s-rk3328/u-boot-2024.01/scripts/dtc/libfdt/fdt.o build/temp.macosx-14.0-arm64-cpython-312/Volumes/Develop/openwrt/build_dir/target-aarch64_generic_musl/u-boot-nanopi-r2s-rk3328/u-boot-2024.01/scripts/dtc/libfdt/fdt_addresses.o build/temp.macosx-14.0-arm64-cpython-312/Volumes/Develop/openwrt/build_dir/target-aarch64_generic_musl/u-boot-nanopi-r2s-rk3328/u-boot-2024.01/scripts/dtc/libfdt/fdt_empty_tree.o build/temp.macosx-14.0-arm64-cpython-312/Volumes/Develop/openwrt/build_dir/target-aarch64_generic_musl/u-boot-nanopi-r2s-rk3328/u-boot-2024.01/scripts/dtc/libfdt/fdt_overlay.o build/temp.macosx-14.0-arm64-cpython-312/Volumes/Develop/openwrt/build_dir/target-aarch64_generic_musl/u-boot-nanopi-r2s-rk3328/u-boot-2024.01/scripts/dtc/libfdt/fdt_ro.o build/temp.macosx-14.0-arm64-cpython-312/Volumes/Develop/openwrt/build_dir/target-aarch64_generic_musl/u-boot-nanopi-r2s-rk3328/u-boot-2024.01/scripts/dtc/libfdt/fdt_rw.o build/temp.macosx-14.0-arm64-cpython-312/Volumes/Develop/openwrt/build_dir/target-aarch64_generic_musl/u-boot-nanopi-r2s-rk3328/u-boot-2024.01/scripts/dtc/libfdt/fdt_strerror.o build/temp.macosx-14.0-arm64-cpython-312/Volumes/Develop/openwrt/build_dir/target-aarch64_generic_musl/u-boot-nanopi-r2s-rk3328/u-boot-2024.01/scripts/dtc/libfdt/fdt_sw.o build/temp.macosx-14.0-arm64-cpython-312/Volumes/Develop/openwrt/build_dir/target-aarch64_generic_musl/u-boot-nanopi-r2s-rk3328/u-boot-2024.01/scripts/dtc/libfdt/fdt_wip.o build/temp.macosx-14.0-arm64-cpython-312/scripts/dtc/pylibfdt/libfdt_wrap.o -L/Volumes/Develop/openwrt/build_dir/target-aarch64_generic_musl/u-boot-nanopi-r2s-rk3328/u-boot-2024.01/scripts/dtc/pylibfdt/../libfdt -o build/lib.macosx-14.0-arm64-cpython-312/_libfdt.cpython-312-darwin.so<http://libfdt.cpython-312-darwin.so>

Apparently it tries to link several files together but it gives the error:

ld: warning: search path '/Volumes/Develop/openwrt/staging_dir/target-aarch64_generic_musl/host/lib' not found
Undefined symbols for architecture arm64: "_PyArg_UnpackTuple", referenced from: _SwigPyObject_own in libfdt_wrap.o "_PyBool_FromLong", referenced from: _SwigPyObject_richcompare in libfdt_wrap.o _SwigPyObject_own in libfdt_wrap.o "_PyByteArray_AsString", referenced from: __wrap_fdt_magic in libfdt_wrap.o __wrap_fdt_totalsize in libfdt_wrap.o __wrap_fdt_off_dt_struct in libfdt_wrap.o __wrap_fdt_off_dt_strings in libfdt_wrap.o __wrap_fdt_off_mem_rsvmap in libfdt_wrap.o __wrap_fdt_version in libfdt_wrap.o __wrap_fdt_last_comp_version in libfdt_wrap.o …

But interestingly enough, when I manually add the library at “/opt/homebrew/Cellar/python at 3.12/3.12.2_1/Frameworks/Python.framework/Versions/3.12/lib/libpython3.12.dylib” to the first gcc command, it runs fine. Hence I think the library is the main problem here.

After executing the modified command, the compile goes on without complaining at “PYMOD rebuild”, but similar problems occured with other libs.

As macOS is a completely POSIX compatible *nix operating system and ARM64 is blooming, I sincerely hope that you guys could consider fix the compiling on Apple Silicon platform. Thanks!

Looking forward to your reply.

Leo Maxwell
Apr 11th, 2024