Over-eager linker resolution?

In !12264 (comment 602406) @christiaanb has raised the following regression turned up by clash-ffi:

Could this MR be the cause of an issue I'm seeing in of our projects: https://gitlab.com/clash-lang/clash-compiler/-/jobs/8751129358, specifically this line of the MR: !12264 (diffs)

So the error that I'm seeing is:

[2 of 2] Linking dist-newstyle/build/x86_64-linux/ghc-9.8.4/clash-ffi-example-0.1.0.0/setup/setup
Configuring clash-ffi-example-0.1.0.0...
Warning: 'include-dirs: ../include' is a relative path outside of the source
tree. This will not work when generating a tarball with 'sdist'.
Preprocessing foreign library 'clash-ffi-example' for clash-ffi-example-0.1.0.0..
Building foreign library 'clash-ffi-example' for clash-ffi-example-0.1.0.0..
<command line>: /builds/clash-lang/clash-compiler/clash-ffi/example/dist-newstyle/build/x86_64-linux/ghc-9.8.4/clash-ffi-1.7.0/build/libHSclash-ffi-1.7.0-inplace-ghc9.8.4.so: undefined symbol: vpi_register_cb
Error: [Cabal-7125]

We only see the error on GHC 9.8.4; it works with GHC 9.8.2 and GHC 9.10.1. This MR seems to be the only symbol loading related MR that is part of GHC 9.8.4, but not of GHC 9.8.2 nor of GHC 9.10.1

By the way, the library with the undefined symbol in questions, does indeed have undefined symbols; but that is by design! And it's the same symbols when compiled against GHC 9.8.4 (the failing GHC), and when compiled on GHC 9.10.1 (the working GHC):

~/devel/clash-compiler/clash-ffi/example/dist-newstyle/build/x86_64-linux/ghc-9.10.1/clash-ffi-1.7.0/build> nm -C -u ../../../ghc-9.8.4/clash-ffi-1.7.0/build/libHSclash-ffi-1.7.0-inplace-ghc9.8.4.so | grep vpi
                 U vpi_chk_error
                 U vpi_compare_objects
                 U vpi_control
                 U vpi_flush
                 U vpi_free_object
                 U vpi_get
                 U vpi_get_str
                 U vpi_get_time
                 U vpi_get_value
                 U vpi_get_vlog_info
                 U vpi_handle
                 U vpi_handle_by_index
                 U vpi_handle_by_multi_index
                 U vpi_handle_by_name
                 U vpi_iterate
                 U vpi_printf
                 U vpi_put_value
                 U vpi_register_cb
                 U vpi_remove_cb
                 U vpi_scan

~/devel/clash-compiler/clash-ffi/example/dist-newstyle/build/x86_64-linux/ghc-9.10.1/clash-ffi-1.7.0/build> nm -C -u libHSclash-ffi-1.7.0-inplace-ghc9.10.1.so  | grep vpi
                 U vpi_chk_error
                 U vpi_compare_objects
                 U vpi_control
                 U vpi_flush
                 U vpi_free_object
                 U vpi_get
                 U vpi_get_str
                 U vpi_get_time
                 U vpi_get_value
                 U vpi_get_vlog_info
                 U vpi_handle
                 U vpi_handle_by_index
                 U vpi_handle_by_multi_index
                 U vpi_handle_by_name
                 U vpi_iterate
                 U vpi_printf
                 U vpi_put_value
                 U vpi_register_cb
                 U vpi_remove_cb
                 U vpi_scan

The idea is that these symbols will be provided by whatever Verilog simulator will load the DLL you end up building. See https://github.com/clash-lang/clash-compiler/blob/master/clash-ffi/README.md for more details.

The reason I'm suspecting the line in question is because when running GHC with full verbosity I see:

Loading unit derive-storable-plugin-0.2.3.7 ... linking ... done.
Loading unit clash-ffi-1.7.0 ... *** Deleting temp files:
Deleting: 
*** Deleting temp subdirs:
Deleting: 
*** Deleting temp dirs:
Deleting: 
<command line>: /home/christiaan/devel/clash-compiler/clash-ffi/example/dist-newstyle/build/x86_64-linux/ghc-9.8.4/clash-ffi-1.7.0/build/libHSclash-ffi-1.7.0-inplace-ghc9.8.4.so: undefined symbol: vpi_register_cb

So it prints the Loading unit clash-ffi-1.7.0 ... part, but never gets to the linking ... part.