#16370: Hadrian: test T3807 failure -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by davide): * owner: (none) => davide * cc: alpmestan, snowleopard, angerman, bgamari (added) Old description:
When building with hadrian, test T3807 fails with a linker error. The test's Makefile attempts to link with the RTS:
{{{ # testsuite/tests/dynlibs/Makefile : 12 '$(TEST_HC)' $(filter-out -rtsopts,$(TEST_HC_OPTS)) -v0 --make -dynamic -fPIC -shared T3807Export.hs T3807-export.c -o T3807test.so -lHSrts- ghc`'$(TEST_HC)' $(TEST_HC_OPTS) --numeric-version` }}}
In particular, this will result in the following linker option that causes the failure (assuming ghc version 8.9.0):
{{{ -lHSrts-ghc8.9.0 }}}
In Hadrian, unlike in make, the RTS library file includes the (dummy) version number, so the required linker option would actually be:
{{{ -lHSrts-1.0-ghc8.9.0 }}}
While it's possible to try and match makes behavior by removing the dummy version from the file names (I've started on that [https://gitlab.haskell.org/DavidEichmann/ghc/commit/f1106d1302e8d4f42778e3df... here]), a further complication arises. Hadrian tries to copy relevant library files using cabal-install's `cabal copy` command. Cabal expects the "1.0" version number to be present and so will fail. In summary, the naming conventions between Hadrian and Cabal would conflict if Hadrian dropped the "1.0" version number for the RTS library files.
Some ideas on how to resolve this:
1. Drop the RTS version number in Hadrian and patch Cabal as well. * Cabal may need a special case for the RTS. * Or is there a better alternative? 2. Keep the RTS version number, but create syslinks of the library files without the RTS version number to allow backwards compatibility. 3. Something else?
New description: When building with hadrian, test T3807 fails with a linker error. The test's Makefile attempts to link with the RTS: {{{ # testsuite/tests/dynlibs/Makefile : 12 '$(TEST_HC)' $(filter-out -rtsopts,$(TEST_HC_OPTS)) -v0 --make -dynamic -fPIC -shared T3807Export.hs T3807-export.c -o T3807test.so -lHSrts- ghc`'$(TEST_HC)' $(TEST_HC_OPTS) --numeric-version` }}} In particular, this will result in the following linker option that causes the failure (assuming ghc version 8.9.0): {{{ -lHSrts-ghc8.9.0 }}} In Hadrian, unlike in make, the RTS library file includes the (dummy) version number, so the required linker option would actually be: {{{ -lHSrts-1.0-ghc8.9.0 }}} While it's possible to try and match makes behavior by removing the dummy version from the file names (I've started on that [https://gitlab.haskell.org/DavidEichmann/ghc/commit/f1106d1302e8d4f42778e3df... here]), a further complication arises. Hadrian tries to copy relevant library files using cabal-install's `cabal copy` command. Cabal expects the "1.0" version number to be present and so will fail. In summary, the naming conventions between Hadrian and Cabal would conflict if Hadrian dropped the "1.0" version number for the RTS library files. The correct way to resolve this is unclear. 2 Ideas are: 1. Drop the RTS version number in Hadrian and patch Cabal as well. * Cabal may need a special case for the RTS. * Or is there a better alternative? 2. Keep the RTS version number, but create syslinks of the library files without the RTS version number to allow backwards compatibility with code that links with the rts. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16370#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler