Looks like ghci would be adversely affected by the patch.

Perhaps we could make the patch behavior conditional on an environment variable that we set when building packages that need it?
Then we don't need to regress ghci, or only when nix libraries are loaded.
I think the reason we're seeing this is that TemplateHaskell reuses ghci infrastructure, but we don't need any dynamic reloading for that, so it's probably fine to use this workaround in the build. See:

GHC Note [RTLD_LOCAL]

Quoting GHC's rts/Linker.c:

  Note [RTLD_LOCAL]
  ~~~~~~~~~~~~~~~~~
  In GHCi we want to be able to override previous .so's with newly
  loaded .so's when we recompile something.  This further implies that
  when we look up a symbol in internal_dlsym() we have to iterate
  through the loaded libraries (in order from most recently loaded to
  oldest) looking up the symbol in each one until we find it.

  However, this can cause problems for some symbols that are copied
  by the linker into the executable image at runtime - see #8935 for a
  lengthy discussion.  To solve that problem we need to look up
  symbols in the main executable *first*, before attempting to look
  them up in the loaded .so's.  But in order to make that work, we
  have to always call dlopen with RTLD_LOCAL, so that the loaded
  libraries don't populate the global symbol table.

Uh oh!

Uh oh!

Build failure: cachix on darwin #461651

Description

Metadata

Metadata

Assignees

Labels

Fields

Projects

Milestone

Relationships

Development

Issue actions