ghc @9.12.2_1: Missing (or bad) C libraries: m, dl, ffi

[tifrueh (Timo Früh)]

Trying to build ghc on the newest macOS 26 Beta results in the following error (full log attached):

Error: [Cabal-4345]
Missing dependencies on foreign libraries:
* Missing (or bad) C libraries: m, dl, ffi
This problem can usually be solved by installing the system packages that provide these libraries (you may need the "-dev" versions). If the libraries are already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where they are.If the library files do exist, it may contain errors that are caught by the C compiler at the preprocessing stage. In this case you can re-run 'Setup configure' with the verbosity flag -v3 to see the error messages.

Note: I wasn't able to find any information on whether problems with ports on Beta versions of macOS should even be reported, so I apologise for the inconvenience if this is not preferred practice, but I thought it might be beneficial to find out what the issue is before the final release of the OS version.

[tifrueh (Timo Früh)]

Full log

[ryandesign (Ryan Carsten Schmidt)]

See wiki:FAQ#prerelease

[tifrueh (Timo Früh)]

Oh, sorry, seems like I didn't search hard enough. Thank you for the pointer! :)

[mattguk (Matt Graham)]

I have this same issue in Tahoe 26.0 (not the beta).

[ryandesign (Ryan Carsten Schmidt)]

On macOS, libm is libSystem, so it not being found is nonsense. Does Cabal keep a log of how it came to this determination? We'd need to see that to make progress. But it may be an upstream issue worth filing with the developers.

[MaintenanceCosts]

Confirming that I, too, have this issue on release Tahoe on Apple Silicon. The error in the log is exactly the same.

[ryandesign (Ryan Carsten Schmidt)]

This is the upstream bug report:

​https://gitlab.haskell.org/ghc/ghc/-/issues/26152

which was closed in favor of:

​https://gitlab.haskell.org/ghc/ghc/-/issues/26166

which is still open. It confirms that the "Missing libraries" message is a red herring and that the real cause is that -undefined dynamic_lookup doesn't work anymore on macOS Tahoe beta, which was reported to Apple as FB18582210, but that this break may be intentional. If true, that would break a billion ports.

However, there's also a comment from yesterday that ghc 9.14.0.20250908 built successfully on macOS Tahoe final, so we should update the port to the fixed version, except that I cannot find a tag for 9.14.0, only for 9.14.1 alpha versions.

[kwolcott]

Hi;

Tahoe (released, not beta, not RC), arm64, ghc build error. Don't think you need my build log; let me know if you do need it.

:info:build Error: [Cabal-4345]
:info:build Missing dependencies on foreign libraries:
:info:build * Missing (or bad) C libraries: m, dl, ffi
:info:build This problem can usually be solved by installing the system packages that provide these libraries (you may need the "-dev" versions). If the libraries are already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where they are.If the library files do exist, it may contain errors that are caught by the C compiler at the preprocessing stage. In this case you can re-run 'Setup configure' with the verbosity flag -v3 to see the error messages.
:info:build Error when running Shake build system:
:info:build   at want, called at src/Main.hs:126:44 in hdrn-0.1.0.0-02fb0253:Main
:info:build * Depends on: binary-dist-dir
:info:build   at apply1, called at src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in shk-0.19.8-c17791b6:Development.Shake.Internal.Rules.Oracle
:info:build * Depends on: OracleQ (ContextDataKey (Context {stage = Stage1, package = Package {pkgType = Library, pkgName = "rts", pkgPath = "rts"}, way = v, iplace = Final}))
:info:build   at need, called at src/Hadrian/Oracles/Cabal/Rules.hs:54:9 in hdrn-0.1.0.0-02fb0253:Hadrian.Oracles.Cabal.Rules
:info:build * Depends on: _build/stage1/rts/setup-config

[ryandesign (Ryan Carsten Schmidt)]

Here is the buildbot log:

​https://build.macports.org/builders/ports-26_arm64-builder/builds/597/steps/install-port/logs/stdio

[ryandesign (Ryan Carsten Schmidt)]

Affected users, please check if an update of the command line tools is available in System Settings > Software Update. If so, please update and then retry the ghc build.

I see that a CLT update is available on the macOS 26 arm64 build machine but I will need to wait until it is not in the middle of a build before I can try updating.

[ryandesign (Ryan Carsten Schmidt)]

Oh well, software update did not help me.

[reneeotten (Renee Otten)]

has duplicate 73024

[ogourgue (Olivier Gourgue)]

Same issue with macOS Tahoe 26.0, Xcode 26.0.1, Command Line Tools for Xcode 26

[ryandesign (Ryan Carsten Schmidt)]

In 775bbace553d3310c9161a8aabf2e9f585c986ae/macports-ports (master):

ghc: Try blacklisting clang > 1700.3

See: #72773

[cjones051073 (Chris Jones)]

Replying to ryandesign:

In 775bbace553d3310c9161a8aabf2e9f585c986ae/macports-ports (master):

ghc: Try blacklisting clang > 1700.3

See: #72773

Doesn't help, I already tried it locally myself. The issue is with the linker, ld, not the compiler per se.

[ryandesign (Ryan Carsten Schmidt)]

Ok thanks. They were wondering about it over in the ghc bug report. I let them know.

[cjones051073 (Chris Jones)]

Note you can get more info with -v on whats neing used - The reproducer in the ticket ​https://gitlab.haskell.org/ghc/ghc/-/issues/26166 is enough to test things here, we don't need to throw updates at the buildbots...

e.g. with clang-18 it still gives the same error

Larissa ~/cernbox/MacPorts/ghc > clang-mp-18  -v main.c -Wl,-undefined,dynamic_lookup -Wl,-u,mytest
clang version 18.1.8
Target: arm64-apple-darwin25.0.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-18/bin
 "/opt/local/libexec/llvm-18/bin/clang" -cc1 -triple arm64-apple-macosx16.0.0 -Wundef-prefix=TARGET_OS_ -Werror=undef-prefix -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -mrelax-all -dumpdir a- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name main.c -mrelocation-model pic -pic-level 2 -mframe-pointer=non-leaf -ffp-contract=on -fno-rounding-math -funwind-tables=1 -target-sdk-version=26.0 -fcompatibility-qualified-id-block-type-checking -fvisibility-inlines-hidden-static-local-var -fbuiltin-headers-in-system-modules -fdefine-target-os-macros -target-cpu apple-m1 -target-feature +zcm -target-feature +zcz -target-feature +v8.5a -target-feature +aes -target-feature +crc -target-feature +dotprod -target-feature +complxnum -target-feature +fp-armv8 -target-feature +fullfp16 -target-feature +fp16fml -target-feature +jsconv -target-feature +lse -target-feature +pauth -target-feature +ras -target-feature +rcpc -target-feature +rdm -target-feature +sha2 -target-feature +sha3 -target-feature +neon -target-abi darwinpcs -debugger-tuning=lldb -fdebug-compilation-dir=/Users/chris/cernbox/MacPorts/ghc -target-linker-version 1221.4 -v -fcoverage-compilation-dir=/Users/chris/cernbox/MacPorts/ghc -resource-dir /opt/local/libexec/llvm-18/lib/clang/18 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -internal-isystem /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/local/include -internal-isystem /opt/local/libexec/llvm-18/lib/clang/18/include -internal-externc-isystem /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include -ferror-limit 19 -stack-protector 1 -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fmax-type-align=16 -fcolor-diagnostics -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /var/folders/97/z7_b52957j36mhz075gflttr0000gn/T/main-6fc460.o -x c main.c
clang -cc1 version 18.1.8 based upon LLVM 18.1.8 default target arm64-apple-darwin25.0.0
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /opt/local/libexec/llvm-18/lib/clang/18/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.
 "/opt/local/libexec/llvm-18/bin/ld" -demangle -lto_library /opt/local/libexec/llvm-18/lib/libLTO.dylib -no_deduplicate -dynamic -arch arm64 -platform_version macos 16.0.0 26.0 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -mllvm -enable-linkonceodr-outlining -o a.out /var/folders/97/z7_b52957j36mhz075gflttr0000gn/T/main-6fc460.o -undefined dynamic_lookup -u mytest -lSystem /opt/local/libexec/llvm-18/lib/clang/18/lib/darwin/libclang_rt.osx.a
Undefined symbols for architecture arm64:
  "mytest", referenced from:
      <initial-undefines>
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[cjones051073 (Chris Jones)]

Same with clang-17, which is the oldest we can currently build on macOS26

Larissa ~/cernbox/MacPorts/ghc > clang-mp-17 -v main.c -Wl,-undefined,dynamic_lookup -Wl,-u,mytest
clang version 17.0.6
Target: arm64-apple-darwin25.0.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-17/bin
 "/opt/local/libexec/llvm-17/bin/clang" -cc1 -triple arm64-apple-macosx16.0.0 -Wundef-prefix=TARGET_OS_ -Werror=undef-prefix -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -mrelax-all -dumpdir a- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name main.c -mrelocation-model pic -pic-level 2 -mframe-pointer=non-leaf -ffp-contract=on -fno-rounding-math -funwind-tables=1 -target-sdk-version=26.0 -fcompatibility-qualified-id-block-type-checking -fvisibility-inlines-hidden-static-local-var -target-cpu apple-m1 -target-feature +v8.5a -target-feature +aes -target-feature +crc -target-feature +dotprod -target-feature +fp-armv8 -target-feature +fp16fml -target-feature +lse -target-feature +ras -target-feature +rcpc -target-feature +rdm -target-feature +sha2 -target-feature +sha3 -target-feature +neon -target-feature +zcm -target-feature +zcz -target-feature +fullfp16 -target-abi darwinpcs -debugger-tuning=lldb -target-linker-version 1221.4 -v -fcoverage-compilation-dir=/Users/chris/cernbox/MacPorts/ghc -resource-dir /opt/local/libexec/llvm-17/lib/clang/17 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -internal-isystem /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/local/include -internal-isystem /opt/local/libexec/llvm-17/lib/clang/17/include -internal-externc-isystem /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include -fdebug-compilation-dir=/Users/chris/cernbox/MacPorts/ghc -ferror-limit 19 -stack-protector 1 -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fmax-type-align=16 -fcolor-diagnostics -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /var/folders/97/z7_b52957j36mhz075gflttr0000gn/T/main-9f7faa.o -x c main.c
clang -cc1 version 17.0.6 based upon LLVM 17.0.6 default target arm64-apple-darwin25.0.0
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /opt/local/libexec/llvm-17/lib/clang/17/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.
 "/opt/local/libexec/llvm-17/bin/ld" -demangle -lto_library /opt/local/libexec/llvm-17/lib/libLTO.dylib -no_deduplicate -dynamic -arch arm64 -platform_version macos 16.0.0 26.0 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -o a.out /var/folders/97/z7_b52957j36mhz075gflttr0000gn/T/main-9f7faa.o -undefined dynamic_lookup -u mytest -lSystem /opt/local/libexec/llvm-17/lib/clang/17/lib/darwin/libclang_rt.osx.a
Undefined symbols for architecture arm64:
  "mytest", referenced from:
      <initial-undefines>
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[cjones051073 (Chris Jones)]

I'm not signed up to the Haskell gitlab and I don't particularly feel like doing so right now, so perhaps you could post the above. Note that the linker used, ld, is the one from the older clang build. /opt/local/libexec/llvm-17/bin/ld - Not sure what the tells us but as this is a older linker that works fine with other OSes and SDKs (I assume) so perhaps its something else.

[cjones051073 (Chris Jones)]

Hang on.... The LLVM specific 'ld' is just a wrapper around /usr/bin/ld

Larissa ~/cernbox/MacPorts/ghc > cat /opt/local/libexec/llvm-17/bin/ld 
#!/bin/bash

if [[ -x /usr/bin/xcrun ]] ; then
    exec /usr/bin/xcrun ld "${@}"
elif [[ -x /usr/bin/ld ]] ; then
    exec /usr/bin/ld "${@}"
else
    exec ld "${@}"
fi

so each compiler is just using /usr/bin/ld in the end...

[cjones051073 (Chris Jones)]

So... switching to the classic linker ld-classic does work.

Larissa ~/cernbox/MacPorts/ghc > clang main.c -Wl,-undefined,dynamic_lookup -Wl,-ld_classic -Wl,-u,mytest
ld: warning: -ld_classic is deprecated and will be removed in a future release
Larissa ~/cernbox/MacPorts/ghc > ./a.out 
Larissa ~/cernbox/MacPorts/ghc > 

so this might offer a work around for now...

[ryandesign (Ryan Carsten Schmidt)]

In 775bbace553d3310c9161a8aabf2e9f585c986ae/macports-ports (master):

ghc: Try blacklisting clang > 1700.3

See: #72773

[pmetzger (Perry E. Metzger)]

cjones: How do you change the Portfile to invoke ld-classic?

[cjones051073 (Chris Jones)]

I quickly tried it when I first suggested it and couldn't get it to work, ghc didn't work with ld-classic unfortunately.

If you wish to experiment yourself, its a bit build specific. One thing you can try is setting

configure.ldflags-append  -Wl,-ld_classic

the other, specific to ghc is if you look at the Port file you will see it sets an LD env var supposedly to control with linker is used (although I had problems with this).

FWIW here is the Portfile as I left it after my attempts...

[pmetzger (Perry E. Metzger)]

I tried similar stuff and it got through stage 1 but died in stage 2.

This is unfortunately a problem for me; Pandoc, Jupyter, and a number of other packages I use daily are dependent on ghc.

[i0ntempest]

Hacky workaround: extract CLT 16.4 pkg and put it at /Library/Developer/CommandLineTools. This will get you a working ghc compiler, and you may reinstall the new CLT back once done.

[pmetzger (Perry E. Metzger)]

Does it need all of CommandLineTools or only the linker? One could put the linker in somewhere and force its use.

More to the point: is there some sort of kludge we could use for the moment in the Portfile that would get us through the few weeks until the ghc people release something that works better?

[essandess (Steve Smith)]

is there some sort of kludge we could use for the moment in the Portfile that would get us through the few weeks until the ghc people release something that works better?

The fallback has always been to use the *-prebuilt binaries rather than the compiled ones. We should probably add this as a variant.

Just figure out which binary distribution runs on the latest macOS, and swap in the prebuilt binaries in place of the compiled build. A version of this is done in the haskell-cabal PG, where it’s necessary to use prebuilt binaries to bootstrap specific Haskell tools that are necessary to build the entire Haskell world.

[cjones051073 (Chris Jones)]

Replying to essandess:

is there some sort of kludge we could use for the moment in the Portfile that would get us through the few weeks until the ghc people release something that works better?

The fallback has always been to use the *-prebuilt binaries rather than the compiled ones. We should probably add this as a variant.

Just figure out which binary distribution runs on the latest macOS, and swap in the prebuilt binaries in place of the compiled build. A version of this is done in the haskell-cabal PG, where it’s necessary to use prebuilt binaries to bootstrap specific Haskell tools that are necessary to build the entire Haskell world.

Doing this by hand is very much not recommended, users should not be altering files inside the MacPorts install prefix manually.

If this is a useful / necessary option then a +prebuilt variant of the ghc port which automates this should indeed be added (probably all that is needed is to override all the usual phases and just create a few sym links to the ghc-prebuilt binaries during destroot to mimic the regular ones ghc would provide if built from source).

[essandess (Steve Smith)]

Please see ​https://github.com/macports/macports-ports/pull/29511

[essandess (Steve Smith)]

In 8c7955e171f6927b9c1405af15aca9e04da67b3f/macports-ports (master):

ghc: Add prebuilt variant as fallback

• Add ghc +prebuilt variant as fallback for cases where ghc cannot be compiled
• Note: subport ghc-prebuilt is necessary to bootstrap Haskell build tools, including port ghc, and (nearly equivalent) port ghc +prebuilt is simply a fallback option when ghc cannot be compiled
• Add proc ghc_prebuilt_commands with common commands for subport ghc-prebuilt and port ghc +prebuilt variant
• Make ghc +prebuilt the default on macOS Tahoe until upstream compile is fixed
• Fix livecheck settings
• Remove unnecessary destroot artifacts from prebuilt that would create conflicts between subport ghc-prebuilt and port ghc +prebuilt variant
• Add explanatory notes on intended purpose of subport ghc-prebuilt and port ghc +prebuilt variant
• Add description for subport hadrian
• Minor whitespace alignment fixes
• See: #72773

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

​https://gitlab.haskell.org/ghc/ghc/-/issues/26166

Several commits have been referenced in that issue over the past few days to eliminate the reliance on undefined symbols. I'm guessing we won't want to try to backport these ourselves and will want to wait for a new upstream release.

[cjones051073 (Chris Jones)]

Replying to ryandesign:

Replying to ryandesign:

​https://gitlab.haskell.org/ghc/ghc/-/issues/26166

Several commits have been referenced in that issue over the past few days to eliminate the reliance on undefined symbols. I'm guessing we won't want to try to backport these ourselves and will want to wait for a new upstream release.

I am not the maintainer of ghc so its up to them really, but I would say the prebuilt variant that was added above and made default for macOS26 and above provides a decent enough workaround for now. Once a full release is made that fixes the build from source option and the port is updated to use that, it can just drop making this variant a default, but keep it as a useful alternative for the future.

[nihilismus (Antonio Hernández Blas)]

Just to let you know, I was facing this issue in:

macOS Sequoia 15.7.1 24G231 arm64
Xcode 26.0.1 17A400 / Command Line Tools 26.0.0.0.1.1757719676
MacPorts 2.11.5
Homebrew 4.6.15-52-gf2cdfda

To fix it I executed:

# sudo port clean ghc

And

# sudo port upgrade ghc +prebuilt

[JoachimRose]

Thank you. This seems to have solved my issue.

Can now install a version of Root6 which relies on the ghc port. macOS 26.0.1 (Tahoe), arm64.

sudo port upgrade outdated               fetches ghc-prebuilt-9.12.2_1.darwin_25.arm64.tbz2  
sudo port install root6 +jupyter         installs   root6 @6.36.04_0+cocoa+davix+gcc15+graphviz+jupyter+opengl+python313+roofit+tmva+xml+xrootd

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

​https://gitlab.haskell.org/ghc/ghc/-/issues/26166

This upstream issue has now been closed as fixed. Hopefully the next release will include these fixes and we can update to it.