[GHC] #16370: Hadrian: test T3807 failure

[GHC]

#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/f1106d1302e8d4f42778e3df19725fb9c767bccf
> 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/f1106d1302e8d4f42778e3df19725fb9c767bccf
 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