[GHC] #11223: Dynamic linker on Windows is unable to link against libmingwex

[GHC]

#11223: Dynamic linker on Windows is unable to link against libmingwex
-------------------------------------+-------------------------------------
        Reporter:  Phyx-             |                Owner:  Phyx-
            Type:  task              |               Status:  new
        Priority:  normal            |            Milestone:  8.2.1
       Component:  Runtime System    |              Version:  7.10.3
  (Linker)                           |
      Resolution:                    |             Keywords:
Operating System:  Windows           |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  crash                              |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #10726            |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Matt):

 I did some testing on how GCC linker and GHC runtime linker resolve
 symobols and I found 2 major differences on how they treat symbols from
 static archives.

 Let me illustrate them on some examples:

 Given two C source files which both have the same function defined:

 {{{
 $ cat test1.c
 int test() {
         return 111;
 }

 $ cat test2.c
 int test() {
         return 555;
 }
 }}}

 C and Haskell program that call our test fuction:

 {{{
 $ cat prog1.c
 #include <stdio.h>

 int test();

 int main(int argc, char **argv) {
         printf("%d\n", test());
         return 0;
 }

 $ cat prog1.hs
 module Main (main) where

 foreign import ccall test :: Int

 main = print test
 }}}

 Build static library from two source files

 {{{
 $ gcc -c test1.c test2.c
 $ ar rcs libtest1.a test1.o
 $ ar rcs libtest2.a test2.o
 }}}

 Now this is where it gets interesting:

 {{{
 $ gcc prog1.c test1.o -L. -ltest2
 $ ./a.exe
 111

 $ gcc prog1.c -L. -ltest1 -ltest2
 $ ./a.exe
 111
 }}}

 As you can see gcc will happily link both programs. Test function was
 resolved from first object file/static library while other one is ignored.

 However GHC runtime linker fails to link both programs with duplicate
 symbols error:

 {{{
 $ ghci prog1.hs test1.o -L. -ltest2
 GHC runtime linker: fatal error: I found a duplicate definition for symbol
    _test
 whilst processing object file
    .\libtest2.a
 ...

 $ ghci prog1.hs -L. -ltest1 -ltest2
 GHC runtime linker: fatal error: I found a duplicate definition for symbol
    _test
 whilst processing object file
    .\libtest2.a
 ...
 }}}

 So this is '''1st major difference''': duplicate symbols from static
 archives seem to be ignored by GCC, while GHC runtime linker errors out on
 them.


 Now the 2nd point. In new 3rd file we define function that calls function
 which isn't defined anywhere.

 {{{
 $ cat test3.c

 /* this function is nowhere defined */
 void bla_bla();

 /* this function is not called at all */
 void test_uncalled() {
         bla_bla();
 }
 }}}

 Make new static library with first object file and this 3rd one that
 contains call to undefined function.

 {{{
 $ gcc -c test3.c
 $ ar rcs libtest3.a test1.o test3.o
 }}}

 And try to run both C and Haskell example:

 {{{
 $ gcc prog1.c -L. -ltest3
 $ ./a.exe
 111

 $ ghci prog1.hs -L. -ltest3
 linking extra libraries/objects failed
 ghc.exe: .\libtest3.a: unknown symbol `_bla_bla'
 }}}

 As you can see GHCi errors out with unknown symbol to function in object
 file we do not call, while GCC seems to ignore it.

 So based on this '''2nd major difference''': GCC seems to ignores symbols
 from object files in static archive which are not used while GHC runtime
 linker tries to eagerly resolve all object files, even those that are not
 called into.

 I think because of this 2nd difference we end up with all kinda strange
 unresolved symbols like `__image_base` and similar which cause so much
 problems.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11223#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler