Loading temp shared object failed: dlopen(/var/folders/I0/... ) Library not loaded: @rpath/libghc_21.dylib

[kencu]

I do not know a lot about building with cabal and ghc, but have built a number of packages so far without trouble.

I will admit up-front that this ghc version is built on an older Apple system using some enhancements that usually work well, in the hopes of allowing software like pandoc to run on older MacOS systems. Having said that, it has been successful building all ghc packages via cabal to date, until this issue arose.

When trying to build this package as part of building pandoc, I ran into an odd linker error I have not seen before:

[ 8 of 10] Compiling Text.Collate.Tailorings [Text.Collate.Collation changed]
ghc: panic! (the 'impossible' happened)
  (GHC version 8.10.4:
	Loading temp shared object failed: dlopen(/var/folders/I0/I0fOotq3ErGZHYxrmmWiqU+++TI/-Tmp-/ghc85250_0/libghc_43.dylib, 5): Library not loaded: @rpath/libghc_21.dylib
  Referenced from: /var/folders/I0/I0fOotq3ErGZHYxrmmWiqU+++TI/-Tmp-/ghc85250_0/libghc_43.dylib
  Reason: image not found

This commit of the library builds without trouble on this system (Apple Darwin Intel 10.6 ghc 8.10.4 or 9.2.5, cabal 3.8):

69e6c3c

the following commit 7756a7f does not build due to:

[3 of 8] Compiling Text.Collate.UnicodeData

src/Text/Collate/UnicodeData.hs:17:1: error:
    Could not load module ‘Data.ByteString.Lex.Integral’
    It is a member of the hidden package ‘bytestring-lexing-0.5.0.9’.
    Perhaps you need to add ‘bytestring-lexing’ to the build-depends in your .cabal file.
    Use -v (or `:set -v` in ghci) to see a list of the files searched for.
   |
17 | import Data.ByteString.Lex.Integral (readHexadecimal, readDecimal)
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

the next commit 47ce5f2 gives this error:

[4 of 8] Compiling Text.Collate.Collation

src/Text/Collate/Collation.hs:272:10: error:
    Ambiguous occurrence ‘readCodePoints’
    It could refer to
       either ‘Text.Collate.UnicodeData.readCodePoints’,
              imported from ‘Text.Collate.UnicodeData’ at src/Text/Collate/Collation.hs:33:34-47
              (and originally defined
                 at src/Text/Collate/UnicodeData.hs:109:1-14)
           or ‘Text.Collate.Collation.readCodePoints’,
              defined at src/Text/Collate/Collation.hs:317:1
    |
272 |     case readCodePoints t of
    |          ^^^^^^^^^^^^^^

and then the next one 45ba318 gives the mentioned linker error:

$ cabal build
Resolving dependencies...
Build profile: -w ghc-8.10.4 -O1
In order, the following will be built (use -v for more details):
 - unicode-collation-0.1.2 (lib) (configuration changed)
Configuring library for unicode-collation-0.1.2..
Preprocessing library for unicode-collation-0.1.2..
Building library for unicode-collation-0.1.2..
[ 1 of 10] Compiling Text.Collate.Lang [/Users/cunningh/ken/unicode-collation/dist-newstyle/build/x86_64-osx/ghc-8.10.4/unicode-collation-0.1.2/build/autogen/cabal_macros.h changed]
[ 2 of 10] Compiling Text.Collate.Trie [/Users/cunningh/ken/unicode-collation/dist-newstyle/build/x86_64-osx/ghc-8.10.4/unicode-collation-0.1.2/build/autogen/cabal_macros.h changed]
[ 4 of 10] Compiling Text.Collate.CombiningClass
[ 5 of 10] Compiling Text.Collate.Normalize
[ 6 of 10] Compiling Text.Collate.Collation
[ 7 of 10] Compiling Text.Collate.TH
[ 8 of 10] Compiling Text.Collate.Tailorings [Text.Collate.Collation changed]
ghc: panic! (the 'impossible' happened)
  (GHC version 8.10.4:
	Loading temp shared object failed: dlopen(/var/folders/I0/I0fOotq3ErGZHYxrmmWiqU+++TI/-Tmp-/ghc85250_0/libghc_43.dylib, 5): Library not loaded: @rpath/libghc_21.dylib
  Referenced from: /var/folders/I0/I0fOotq3ErGZHYxrmmWiqU+++TI/-Tmp-/ghc85250_0/libghc_43.dylib
  Reason: image not found

Please report this as a GHC bug:  https://www.haskell.org/ghc/reportabug

I'm not really sure what is happening to cause this linker issue. I thought perhaps you might recognize what is going on. I'll enclose the full verbose build log.

Thanks for any insights you might have.

[kencu]

verbose build failure.log

[jgm]

Sorry, I have no idea! There's nothing in these commits that points to any obvious explanation.

[jgm]

PS this surely has to do with TemplateHaskell which is used in this library.
The TemplateHaskell requires compile-time loading of libghc, I assume, and that's what is failing in your case.

[kencu]

Thanks for that clue. I will look into that.

I don't think there is anything in this library that seems to need fixing. Appreciate your thoughts.

[kencu]

I did get this to build, by setting the TMPDIR to something local, and asking ghc to not delete temp files.

Then when it failed the first time through, I set DYLD_LIBRARY_PATH to the appropriate temp dir where the dylib was. The second time through the build, it used the (identical) dylib it now found from the first failed build, and finished.

Hopefully upstream might give me some code to add to the ghc or cabal dylib link script that adds an rpath to the needed temp dir where the dylibs are being generated.

[jgm]

Great! Maybe this issue can be closed, then, if it's really a cabal issue?

[kencu]

thanks for your thoughts…K