[MacPorts] #70859: gmp @6.3.0: tests fail when built with clang on Intel only, but pass when assembly is disabled. Forcing ld_classic appears to fix the issue.

[MacPorts]

#70859: gmp @6.3.0: tests fail when built with clang on Intel only, but pass when
assembly is disabled. Forcing ld_classic appears to fix the issue.
-----------------------+---------------------------------
  Reporter:  haberg-1  |      Owner:  MarcusCalhoun-Lopez
      Type:  defect    |     Status:  assigned
  Priority:  Normal    |  Milestone:
 Component:  ports     |    Version:
Resolution:            |   Keywords:  ventura
      Port:  gmp       |
-----------------------+---------------------------------

Comment (by markmentovai):

 Replying to [comment:57 cjones051073]:
 > Could you see if adding
 >
 > {{{
 > use_autoconf        yes
 > }}}
 >
 > helps, instead of that patch ? If memory serves that triggers a rerun of
 the autoconf utility before the build.

 MacPorts’ gmp package is unaffected, because it always builds with
 `MACOSX_DEPLOYMENT_TARGET` set, which even under the older libtool doesn’t
 cause `-flat_namespace` to be used. (Incidentally, it also causes
 `-Wl,-undefined,dynamic_lookup` to not be specified, but gmp doesn’t
 actually require this, so it’s fine.)

 This bug as I understand it is about building gmp outside of MacPorts:

 > GMP 'make check' fails when built with later versions of Clang, but
 passes when built with GCC, so that should be the build dependency. Tried
 on MacOS 14. See:
 >
 > ​https://gmplib.org/list-archives/gmp-bugs/2024-June/005505.html
 >
 > ​https://gmplib.org/list-archives/gmp-bugs/2024-July/005506.html

 This refers to `make check` and not MacPorts’ `port check`, and seems to
 mean that when building outside of MacPorts, a failure was observed with
 clang but not with gcc. This would have been before
 [https://github.com/macports/macports-
 ports/commit/2453011ee18c25153b716a2ae42bed85ed52752a 2453011ee18c] and
 [https://github.com/macports/macports-
 ports/commit/771b2dab4689fd4a17b1293a5b534f42d83fff9b 771b2dab4689], so
 MacPorts gcc would have been using `ld -ld_classic`.

 We now understand:
  - The problem is in the linker, not the compiler. The bug can occur with
 any compiler, Xcode’s or MacPorts’. It can also be avoided with any
 compiler by forcing the use of `ld -ld_classic`, although that’s not the
 best solution.
  - The linker bug occurs using ld-new/ld-prime targeting x86_64 and using
 `-flat_namespace`. It’s a bug in gmp’s build system that `-flat_namespace`
 is used at all, and this bug can be fixed by gmp picking up new build
 dependencies (in particular, libtool) that already fixed this bug a couple
 of years ago.
  - MacPorts’ own build of gmp is not affected by the bug, because
 `MACOSX_DEPLOYMENT_TARGET` during its build. There is no reason to fear
 any particular compiler when MacPorts builds gmp.

 Given the new understanding, in light of how this bug was originally
 filed, I think that it should be closed with no action.

 I left the patch file here to “show work”, but given the above, don’t
 think MacPorts needs to take it. `use_autoconf`/`use_autoreconf` might not
 work in this instance anyway, since (as is typical for autotools-based
 projects) gmp seems tied to specific versions of autoconf and automake,
 and those are not the current versions in MacPorts. In order to regenerate
 these files, I had to use autoconf269 and automake115, and place symbolic
 links from ${prefix}/share/automake115/aclocal to ../../aclocal for a
 variety of libtool’s m4 files. That’s why I called it fiddly.

-- 
Ticket URL: <https://trac.macports.org/ticket/70859#comment:58>
MacPorts <https://www.macports.org/>
Ports system for macOS