tk @8.6.14 +quartz +universal: libtk8.6.dylib is a text file

[ned-deily (Ned Deily)]

Attempting to install tk with the +quartz and +universal variants from source (on macOS 15.1.1 Apple Silicon Mac) results in a text file being installed in $PREFIX/lib/libtk8.6.dylib rather than the expected shared library. (FTR, this macports installation has a non-standard install prefix but I don't expect that this is a factor here.) Without the +universal variant (just +quartz), the shared library is installed as expected. The build, install, or activate of the tk +quartz +universal port variant does not fail but builds of dependent ports, like py312-tkinter +universal will fail because of the bogus dylib file.

# port activate tk @8.6.14_0+quartz
--->  Computing dependencies for tk
--->  Deactivating tk @8.6.14_0+quartz+universal
--->  Cleaning tk
--->  Activating tk @8.6.14_0+quartz
--->  Cleaning tk
# file /opt/macports/lib/libtk8.6.dylib
/opt/macports/lib/libtk8.6.dylib: Mach-O 64-bit dynamically linked shared library arm64
# port activate tk @8.6.14_0+quartz+universal
--->  Computing dependencies for tk
--->  Deactivating tk @8.6.14_0+quartz
--->  Cleaning tk
--->  Activating tk @8.6.14_0+quartz+universal
--->  Cleaning tk
# file /opt/macports/lib/libtk8.6.dylib
/opt/macports/lib/libtk8.6.dylib: ASCII text, with very long lines (391)
# more /opt/macports/lib/libtk8.6.dylib
Binary files /opt/macports/var/macports/build/_opt_macports_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_x11_tk/tk/work/destroot-arm64//opt/macports/lib/libtk8.6.dylib and /opt/macports/var/macports/build/_opt_macports_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_x11_tk/tk/work/destroot-ppc-intel//opt/macports/lib/libtk8.6.dylib differ

[ryandesign (Ryan Carsten Schmidt)]

It looks like you're showing us that the bad libtk8.6.dylib file contains the text

Binary files /opt/macports/var/macports/build/_opt_macports_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_x11_tk/tk/work/destroot-arm64//opt/macports/lib/libtk8.6.dylib and /opt/macports/var/macports/build/_opt_macports_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_x11_tk/tk/work/destroot-ppc-intel//opt/macports/lib/libtk8.6.dylib differ

? That should of course not be in that file; that's a message that the muniversal portgroup should be outputting into the main.log.

Can you repeat the build up to the destroot phase (sudo port clean tk && sudo port destroot tk +quartz +universal) to generate a new main.log and then attach that main.log? port logfile tk tells you where it is.

[ned-deily (Ned Deily)]

Log of "port destroot tk +quartz +universal"

[ryandesign (Ryan Carsten Schmidt)]

I see this surprising line in the log:

:info:destroot fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: /opt/macports/var/macports/build/_opt_macports_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_x11_tk/tk/work/destroot-arm64//opt/macports/lib/libtk8.6.dylib and /opt/macports/var/macports/build/_opt_macports_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_x11_tk/tk/work/destroot-ppc-intel//opt/macports/lib/libtk8.6.dylib have the same architectures (arm64) and can't be in the same fat output file

They should not, of course, have the same architecture; one should be arm64 and the other should be x86_64. And the earlier compile commands do seem to use -arch arm64 and -arch x86_64 as they should.

libtk8.6.dylib isn't the only file where lipo complains that the two files have the same arch; the same complaint is issued for libtkstub8.6.a and wish8.6.

For comparison, this doesn't happen for me on macOS 12 on x86_64; it may be specific to macOS ≥ 15 or to arm64.

[ryandesign (Ryan Carsten Schmidt)]

I take it back, I do see this problem on macOS 12 x86_64.

From your log:

checking if compiler accepts -arch arm64 flag... yes

The build is second-guessing our arch choices. It is auto-adding -arch arm64 to the Intel portion of your build; on my Intel machine, it is auto-adding -arch x86_64 to the ARM portion of the build. This happens because we are using the --enable-64bit configure flag. I don't know if we can simply remove that configure flag or whether that has additional undesirable consequences.

[ryandesign (Ryan Carsten Schmidt)]

I filed an upstream bug report to inquire how we should resolve this:

​https://core.tcl-lang.org/tk/tktview/7fe55e86f1284847b53687c4f8af7727a5c1cfe4