Why does cabal(or ghc) look for symbols in .so while building?

bglgwyng · May 30, 2025, 6:03am

Here is the reproducer

When I run cabal build foofoo, then the following error occurs.

Building executable 'foofoo' for foofoo-0.1.0.0...
<command line>: /nix/store/9h6k3lj5dw777hs6dzkw924lx4m62sqf-gsl-2.8/lib/libgsl.so: undefined symbol: cblas_ctrmv
Error: [Cabal-7125]
Failed to build exe:foofoo from foofoo-0.1.0.0.

There is no context provided, so I don’t know why cabal looks up the symbol. While I know that I added hmatrix-gsl as a dependency, I don’t understand symbol lookup happening in the build stage.

The following is the result of cabal build foofoo --verbose, but I can’t find any hint from it.

Configuration is affected by the following files:
- cabal.project
Build profile: -w ghc-9.8.4 -O1
In order, the following will be built:
 - foofoo-0.1.0.0 (exe:foofoo) (file app/Main.hs changed)
Executing install plan in parallel using Just 8 threads.
creating
/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build
creating
/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/tmp
creating
/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo
creating
/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo/cache
Using self-exec internal setup method with build-type Simple and args:
["act-as-setup","--build-type=Simple","--","--working-dir=/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/foofoo","build","--verbose=2","--builddir=/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo"]
/nix/store/n7ar7icxa6sh6cr3y9aq619xbyvzv1nw-cabal-install-3.14.2.0/bin/.cabal-wrapped
act-as-setup --build-type=Simple --
--working-dir=/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/foofoo
build --verbose=2
--builddir=/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo
Including the following directories in PATH:
- /home/bglgwyng/.cabal/bin
Including the following environment variable overrides:
-
foofoo_datadir=/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/foofoo/.
Running: /nix/store/n7ar7icxa6sh6cr3y9aq619xbyvzv1nw-cabal-install-3.14.2.0/bin/.cabal-wrapped act-as-setup '--build-type=Simple' -- '--working-dir=/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/foofoo' build '--verbose=2' '--builddir=/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo'
Component build order: executable 'foofoo'
Running: /nix/store/av09skr6hs60k9q70a684ypgg4v0j3ii-ghc-9.8.4-with-packages/bin/ghc-pkg init /home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo/package.conf.inplace
creating
/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo/build/foofoo
creating
/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo/build/foofoo/autogen
creating
/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo/build/foofoo/autogen
creating
/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo/build/foofoo/autogen
creating
/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo/build/foofoo/autogen
Preprocessing executable 'foofoo' for foofoo-0.1.0.0...
Building executable 'foofoo' for foofoo-0.1.0.0...
creating
/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo/build/foofoo
creating
/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo/build/foofoo/foofoo-tmp
Wanted module build ways(executable 'foofoo'): [StaticWay]
Final module build ways(executable 'foofoo'): [StaticWay]
Running: /nix/store/av09skr6hs60k9q70a684ypgg4v0j3ii-ghc-9.8.4-with-packages/bin/ghc --make -no-link -fbuilding-cabal-package -O -static -outputdir /home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo/build/foofoo/foofoo-tmp -odir /home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo/build/foofoo/foofoo-tmp -hidir /home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo/build/foofoo/foofoo-tmp -hiedir /home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo/build/foofoo/foofoo-tmp/extra-compilation-artifacts/hie -stubdir /home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo/build/foofoo/foofoo-tmp -i -iapp -i/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo/build/foofoo/foofoo-tmp -i/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo/build/foofoo/autogen -i/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo/build/global-autogen -I/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo/build/foofoo/autogen -I/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo/build/global-autogen -I/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo/build/foofoo/foofoo-tmp -optP-include -optP/home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo/build/foofoo/autogen/cabal_macros.h -this-unit-id foofoo-0.1.0.0-inplace-foofoo -hide-all-packages -Wmissing-home-modules -no-user-package-db -package-db /home/bglgwyng/.cabal/store/ghc-9.8.4-6de5/package.db -package-db /home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/packagedb/ghc-9.8.4 -package-db /home/bglgwyng/Documents/GitHub/ghc-typelits-knownnat-fails-build/dist-newstyle/build/x86_64-linux/ghc-9.8.4/foofoo-0.1.0.0/x/foofoo/package.conf.inplace -package-id base-4.19.2.0-213b -package-id ghc-typelits-knownnat-0.7.13-Lr0qQrA5hAd5DsF2uqN7s4 -package-id hmatrix-gsl-0.19.0.1-8XOjr9s3Boq2ooB3aOLIFC -XHaskell2010 app/Main.hs -Wall -fplugin GHC.TypeLits.KnownNat.Solver -hide-all-packages
<command line>: /nix/store/9h6k3lj5dw777hs6dzkw924lx4m62sqf-gsl-2.8/lib/libgsl.so: undefined symbol: cblas_ctrmv
Error: [Cabal-7125]
Failed to build foofoo-0.1.0.0-inplace-foofoo.
CallStack (from HasCallStack):
  dieWithException, called at src/Distribution/Client/ProjectOrchestration.hs:1241:21 in cabal-install-3.14.2.0-BnTiwbjjLNE5bYFohs0LgY:Distribution.Client.ProjectOrchestration

Can someone explain this issue and how to solve it?

adamgundry · May 30, 2025, 7:04am

GHC needs to lookup symbols in the build stage because you are using -fplugin, which inherently involves dynamically loading code for the plugin into the compiler process. You might reasonably object that it doesn’t need to dynamically link libgsl in order to run a plugin from ghc-typelits-knownnat, but unfortunately I don’t think GHC/Cabal have a very good story about dependency tracking for plugins as yet.

You may be able to work around this by reorganising your Cabal package(s) so that -fplugin is used only in components without the libgsl dependency, or there’s also a (sadly under-documented and dangerous) -fplugin-package option that might help. Some possibly useful links:

github.com/haskell/cabal

RFC: design for better GHC plugin support in cabal

opened 01:51PM - 11 Jan 22 UTC

michaelpj

type: discussion type: RFC re: ghc-plugins

This came out of some discussion on IRC. I started writing an issue, but on refl…ection I think there's a relatively plausible design sitting there, so I wrote it down. # Motivation GHC compiler plugins are currently not terribly easy to use with `cabal`, and require some amount of manual fiddling. In addition, they are not specified as declaratively as they could be (i.e. cabal has no concept of a "plugin"), which prevents cabal from doing some things as well as it could do. I think there are two broad kinds of plugin that we should be thinking about: 1. Package plugins Package plugins are those which are required by the package itself. They usually have a load-bearing role, in that they are actually necessary to compile the package. An example is the `record-dot-preprocessor` plugin. Today, these can be used by: - Adding the plugin package to the component's `build-depends` stanza - Passing the appropriate `-fplugin` GHC option Package plugins as implemented today have a few weaknesses: - They don't use `-fplugin-package`, since they are just specified as normal `build-depends`. This means they get unnecessarily linked into the final build product (https://github.com/haskell/cabal/issues/6169). - They are solved for as part of the main build plan, even though (see above) they don't need to be linked into the final build product. - If/when the upstream GHC support for a native package db for plugins is completed, cabal will not be able to use it (because it doesn't know they're plugins). - Users have to specify the `-fplugin` options themselves, as well as any `-fplugin-opt` flags. 2. Global plugins Global plugins are ones which users want to run on all packages that get built, regardless of whether the package itself says it requires any plugins. An example is the `ghc-tags-plugin` plugin. Often these are used to e.g. get additional compile-time information out of dependencies. Today these are very difficult to use (https://github.com/haskell/cabal/issues/7685, https://github.com/haskell/cabal/issues/6307, probably more). Partly the issue is that doing this nicely requires both setting a GHC option for upstream packages (doable today in `cabal.project`), but also building the plugin package and ensuring it is present in the appropriate package db when building the upstream package (hard to do without hacks like specifying your own manually created plugin db). Since these sorts of plugins are also frequently used just in development, it would be particularly nice if they could easily be specified via `cabal.project.local` (https://github.com/haskell/cabal/issues/6169#issuecomment-593062344). ## Proposal 1. `plugin-depends` field for `.cabal` files (Prior art: https://github.com/haskell/cabal/issues/2965, but I'm putting it a little differently, so I'll repeat.) The goal here is to make the situation nicer for package plugins. To that end, we teach cabal a `plugin-depends` field for component stanzas for `.cabal` files. `plugin-depends` contains a list of package/module pairs. Initially, it could start out as a simple wrapper for `build-depends`, and then we could progressively augment it to have the following features: - Also imply the appropriate `-fplugin` flags. (This is why we need the module component! `-fplugin` needs the actual plugin module.) - Be passed via `-fplugin-package` (in particular, I don't think this needs to be a prerequisite, contra https://github.com/haskell/cabal/issues/6307#issuecomment-607146612) - Be included in an appropriate native package db when/if that exists - Be solved for as part of an independent build plan for native dependencies (relies on the previous item) This deliberately doesn't cover `-fplugin-opt` flags. It seems reasonable for users to add those themselves. (I'm also disagreeing with [my past self](https://github.com/haskell/cabal/issues/2965#issuecomment-607271932) here, who thought that we should just have `native-build-depends` and have that include plugins. However, the idea of including the extra information about modules that's needed to automatically pass `-fplugin` flags seems appealing to me, and requires a plugin-specific field. You *could* do this with a combination of `native-build-depends` and `active-plugins` (the latter taking a list of modules); maybe that would be nicer.) 2. `plugin-depends` package field for `cabal.project` files The goal here is to make the situation nicer for global plugins. To that end, we teach cabal a `plugin-depends` field for package stanzas in `cabal.project` files. This field simply augments the `plugin-depends` field for the corresponding package. Plugins that truly want to be globally applied can then use `package *` as usual.

https://downloads.haskell.org/ghc/9.8.3/docs/libraries/ghc-9.8.3-c39e/src/GHC.Driver.Plugins.External.html

bglgwyng · May 30, 2025, 7:33am

Thank you for your kind response!

Topic		Replies	Views
GHC's -fplugin - Any changes between 9.4.7 and 9.6.2? Learn	4	957	November 27, 2023
GHCI with transitive dynamic library dependency fails to properly resolve symbols Learn	2	309	February 10, 2024
GHC and Cabal: the big picture Learn	28	4066	July 18, 2024
Why is cabal install foo --lib frowned upon? Learn	22	2142	September 15, 2023
Is every hackage package buildable? Learn	30	1426	December 2, 2023

Why does cabal(or ghc) look for symbols in .so while building?

Related topics