linker_unload

[Herbert Valerio Riedel]

On 2014-12-03 at 09:48:58 +0100, Simon Peyton Jones wrote:
> I did the Ubuntu upgrade thing, and it's still happening for me too.
>
> I have no idea how to narrow it down some more.

I had a short conversation w/ Joachim on #ghc, and what we know so far:

For a non-failing linker_unload environment, the testprogram is linked
against libgmp.so:

$ ldd tests/rts/linker_unload 
	linux-vdso.so.1 =>  (0x00007fff20f6c000)
	libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f83c5bbb000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f83c58b5000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f83c56ac000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f83c54a8000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f83c50e3000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f83c4ec4000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f83c5e76000)

Also, in the reported test failure, the failure occurs when calling
resolveObjs() on the Test.o file (after the libHS-libs were already
succesfully loadPkg()ed)


        r = loadObj(OBJPATH);
        if (!r) {
            errorBelch("loadObj(%s) failed", OBJPATH);
            exit(1);
        }
        r = resolveObjs();
        if (!r) {
            errorBelch("resolveObjs failed");
            exit(1);
        }


Alas we still don't know what property of the build-environment
determines whether this test fails or succeeds... :-/