#5435: GHCi linker should run constructors for linked libraries -------------------------------------+------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: 7746, 8199 | Related Tickets: #3658 -------------------------------------+------------------------------------ Comment (by ezyang): While fixing this, I found a few more bugs, which are going to be a bit annoying to fix: * The current dynamic test is really a test for loading a static library that happens to be PIC'd. We need to explicitly use addDLL to load a shared library. In fact, we can run a statically linked executable and still load a DLL. * But we can't reuse this test for Windows, because on Linux/Mac OS X, addDLL requires a file extension, while on Windows, we must omit it. So we need two tests here. * Also, on Windows, when I pass `-dynamic` when building the C DLL causes errors like `C:/Users/ezyang/Dev/ghc-init/inplace/mingw/bin/ld.exe: cannot find -lHSbase-4.7.0.0-ghc7.7.20130905`; no problem, just omit the flag. But this is harmless on Linux, so maybe there is a bug here. * With the dynamic test working, I found that actually, `ctors` is reversed, so I need to revert the behavior back to the reversed version. (I had it that way originally, but flipped it due to the buggy test case) * Then I found out that, actually, the order MingW GCC compiles `__attribute__(constructor)` to run is reverse of how it compiles it on Linux. I think this might be a bug, but I couldn't find anywhere where GCC said that they were going to run in any specific order. But this means to keep the test cases consistent, we need to manually lay out the ctors section ourself. No problem, so we need two tests: one for a C compilation, and one for a assembly compilation (with all of the various ways an initializer can be spelled). Obviously this doesn't apply to Mach-O. * Then I wondered, "Well, what happens if there are both ctors and init_array and init; is there a prescribed order these should run in, or is it just the order they show up in the sections?" Well, the dynamic linker will guidance here. * I also tried to induce ordering with priority, but I found out that GCC compiles constructor priority by tacking on a number to the name of the ctors section; I didn't write support for that but maybe I should. * And then Anders pointed out to me that in C++, the order of constructors in the compilation unit is guaranteed, and it seems unlikely GCC would use priority to manage that, so that would be an easy way to find out if MingW GCC was buggy; but if it is buggy, what can we do? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/5435#comment:29 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler