`ld: unknown option: -no_fixup_chains` when compiling the `semigroups` package on macos 10.14

[lgoettgens]

I just tried to build the GAP 4.16.0-beta1 release, including the package distro in julia's binarybuilder, for later use in GAP.jl. This worked mostly fine, but there is a build issue with the semigroups package.

The concrete build script is located at JuliaPackaging/Yggdrasil@master...lgoettgens:Yggdrasil:lg/GAP_pkg#diff-61eaa7b76daf9fe3b10cedcc71d4ff2e6aae5e1fa8bc15742a7cba96d0a673b6.
The error I get on aarch64-apple-darwin20 (which is the alphabetically first Apple architecture) is

[...]
[16:28:51] c++ -pthread -g -O2 -fno-common -MQ gen/gapbind14/src/gapbind14.o -MMD -MP -MF gen/gapbind14/src/gapbind14.d -I/workspace/destdir/include -I/workspace/destdir/include/libsemigroups
 -std=gnu++17 -O3 -Wno-unused-command-line-argument -flax-vector-conversions -Igapbind14/include/ -DFMT_HEADER_ONLY -DNDEBUG -o gen/gapbind14/src/gapbind14.o -I/workspace/destdir/include/gap/
extra -DUSE_JULIA_GC=1 -c gapbind14/src/gapbind14.cpp
[16:31:14] g++  -o bin/aarch64-apple-darwin20-julia1.14-64-kv10/semigroups.so  -L/workspace/destdir/lib -lgap -bundle -undefined dynamic_lookup -Wl,-no_fixup_chains gen/src/bipart.o gen/src/c
onglatt.o gen/src/froidure-pin-fallback.o gen/src/isomorph.o gen/src/pkg.o gen/src/to-gap.o gen/src/init-cong.o gen/src/init-froidure-pin-base.o gen/src/init-froidure-pin-bipart.o gen/src/ini
t-froidure-pin-bmat.o gen/src/init-froidure-pin-matrix.o gen/src/init-froidure-pin-max-plus-mat.o gen/src/init-froidure-pin-min-plus-mat.o gen/src/init-froidure-pin-pbr.o gen/src/init-froidur
e-pin-pperm.o gen/src/init-froidure-pin-transf.o gen/src/init-presentation.o gen/src/init-sims.o gen/src/init-to-congruence.o gen/src/init-to-froidure-pin.o gen/src/init-todd-coxeter.o gen/ga
pbind14/src/gapbind14.o -Wl,-rpath,/workspace/destdir/lib/pkgconfig/../../lib -L/workspace/destdir/lib/pkgconfig/../../lib -lsemigroups
[16:31:14] ld: unknown option: -no_fixup_chains
[16:31:14] collect2: error: ld returned 1 exit status
[16:31:14] make: *** [Makefile.gappkg:141: bin/aarch64-apple-darwin20-julia1.14-64-kv10/semigroups.so] Error 1

Note that the build script explicitly uses the macOS 10.14 SDK. The build argument in question was introduced in #5789 by @fingolfin. (at least this is the only mention of that flag that I found in the repositories in question)

According to haskell/zlib#53 (comment), the -no_fixup_chains option was dropped from macOS 10.13. It would be good if someone who knows a bit about macOS could have a look at this (before the 4.16.0 release).

cc @fingolfin @jswent

[jswent]

I checked and -no_fixup_chains is still valid on my mac (15.6.1) system version of ld. It looks to me that the version of ld used when building the JLL is not the macos native version (since macos throws ld: unknown options - note the "s") which is likely due to this commit in Yggdrasil which forces using gcc/g++ which links via collect2 -> cctools-port ld

I also found a similar case in Yggdrasil which required stripping out this argument here - so that could be a solution if keeping the flag is desirable

[fingolfin]

Yeah indeed: -no_fixup_chains is alive and kicking on macOS, but IIRC Yggdrasil uses a custom linker, not Apple's ld, and this has caused issues in the past.

Anyway this goes back to PR #5789 and was specifically added for GAP-in-Julia. I need to think a bit about it to recall everything, but basically: we use that option to avoid warnings about using -undefined dynamic_lookup, namely:

ld: warning: -undefined dynamic_lookup may not work with chained fixups

Again IIRC we could "simply" move away from that, but this other effects (like... break compat with older macOS versions? Again, I don't quite remember and will have to have a closer look)

[fingolfin]

(on the long run, PR #5780 side steps all of this. But even if I completed that tomorrow, I would not want to merge this for GAP 4.16.0 as it has the potential to be quite breaking.

[fingolfin]

I think for this release, we'd indeed be best off simply patching out -no_fixup_chains as suggested by @jswent

[lgoettgens]

I think for this release, we'd indeed be best off simply patching out -no_fixup_chains as suggested by @jswent

I'll try that later today. If it works, feel free to move this issue here to a more distant future milestone or so.

[lgoettgens]

I think for this release, we'd indeed be best off simply patching out -no_fixup_chains as suggested by @jswent

I'll try that later today. If it works, feel free to move this issue here to a more distant future milestone or so.

It seems to have worked.