I'm getting this for test linker_unload on Linux. I'm sure it's not my fault! But it makes validate fail Simon Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: linker_unload: /5playpen/simonpj/HEAD-2/libraries/integer-gmp2/dist-install/build/libHSinteg_2MbWUstH60IEgCAexOk3v3.a: unknown symbol `__gmpn_rshift' linker_unload: resolveObjs failed make[3]: *** [linker_unload] Error 1 *** unexpected failure for linker_unload(normal)
Herbert, perhaps this is integer-gmp2 breakage? On 21/11/2014 13:51, Simon Peyton Jones wrote:
I’m getting this for test linker_unload on Linux. I’m sure it’s not my fault!
But it makes validate fail
Simon
Wrong exit code (expected 0 , actual 2 )
Stdout:
Stderr:
linker_unload: /5playpen/simonpj/HEAD-2/libraries/integer-gmp2/dist-install/build/libHSinteg_2MbWUstH60IEgCAexOk3v3.a: unknown symbol `__gmpn_rshift'
linker_unload: resolveObjs failed
make[3]: *** [linker_unload] Error 1
*** unexpected failure for linker_unload(normal)
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
On 2014-11-24 at 11:19:43 +0100, Simon Marlow wrote:
linker_unload: /5playpen/simonpj/HEAD-2/libraries/integer-gmp2/dist-install/build/libHSinteg_2MbWUstH60IEgCAexOk3v3.a: unknown symbol `__gmpn_rshift'
Herbert, perhaps this is integer-gmp2 breakage?
...can't rule it out, but I haven't seen that failure anywhere else so far (including http://haskell.inf.elte.hu/builders/) and can't reproduce it myself either :-/ Cheers, hvr
On 11/24/14 01:50 PM, Herbert Valerio Riedel wrote:
On 2014-11-24 at 11:19:43 +0100, Simon Marlow wrote:
linker_unload: /5playpen/simonpj/HEAD-2/libraries/integer-gmp2/dist-install/build/libHSinteg_2MbWUstH60IEgCAexOk3v3.a: unknown symbol `__gmpn_rshift'
Herbert, perhaps this is integer-gmp2 breakage?
...can't rule it out, but I haven't seen that failure anywhere else so far (including http://haskell.inf.elte.hu/builders/) and can't reproduce it myself either :-/
Have you tested RHEL 6.x? IIRC it is also using older GMP like Solaris... Also this is probably not tested on any builder... Karel
Hi, Am Montag, den 24.11.2014, 13:50 +0100 schrieb Herbert Valerio Riedel:
On 2014-11-24 at 11:19:43 +0100, Simon Marlow wrote:
linker_unload: /5playpen/simonpj/HEAD-2/libraries/integer-gmp2/dist-install/build/libHSinteg_2MbWUstH60IEgCAexOk3v3.a: unknown symbol `__gmpn_rshift'
Herbert, perhaps this is integer-gmp2 breakage?
...can't rule it out, but I haven't seen that failure anywhere else so far (including http://haskell.inf.elte.hu/builders/) and can't reproduce it myself either :-/
I can confirm this on my performance builder machine (Ubuntu 13.10): Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: linker_unload: /data1/ghc-builder/logs/ghc-tmp-REV/libraries/integer-gmp2/dist-install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a: unknown symbol `__gmpn_rshift' linker_unload: resolveObjs failed make[3]: *** [linker_unload] Fehler 1 *** unexpected failure for linker_unload(normal) Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
Hi, Am Mittwoch, den 03.12.2014, 09:25 +0100 schrieb Joachim Breitner:
I can confirm this on my performance builder machine (Ubuntu 13.10):
and on Ubuntu 14.04. Reported as http://ghc.haskell.org/trac/ghc/ticket/9856 This was clearly triggered by the integer-gmp2 commit. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
On 2014-12-03 at 09:38:09 +0100, Joachim Breitner wrote:
Am Mittwoch, den 03.12.2014, 09:25 +0100 schrieb Joachim Breitner:
I can confirm this on my performance builder machine (Ubuntu 13.10):
and on Ubuntu 14.04. Reported as http://ghc.haskell.org/trac/ghc/ticket/9856
This was clearly triggered by the integer-gmp2 commit.
...but why don't we see it everywhere (I for one have never experienced the linker_unload failure myself (which makes it difficult to debug...), and neither did Phab)? What's triggering it only on some configurations? Cheers, hvr
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. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | Joachim Breitner | Sent: 03 December 2014 08:26 | To: ghc-devs@haskell.org | Subject: Re: linker_unload | | Hi, | | | Am Montag, den 24.11.2014, 13:50 +0100 schrieb Herbert Valerio Riedel: | > On 2014-11-24 at 11:19:43 +0100, Simon Marlow wrote: | > >> linker_unload: | > >> /5playpen/simonpj/HEAD-2/libraries/integer-gmp2/dist- | install/build/libHSinteg_2MbWUstH60IEgCAexOk3v3.a: | > >> unknown symbol `__gmpn_rshift' | > | > > Herbert, perhaps this is integer-gmp2 breakage? | > | > ...can't rule it out, but I haven't seen that failure anywhere else | so | > far (including http://haskell.inf.elte.hu/builders/) and can't | > reproduce it myself either :-/ | | I can confirm this on my performance builder machine (Ubuntu 13.10): | | Wrong exit code (expected 0 , actual 2 ) | Stdout: | | Stderr: | linker_unload: /data1/ghc-builder/logs/ghc-tmp-REV/libraries/integer- | gmp2/dist-install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a: unknown | symbol `__gmpn_rshift' | linker_unload: resolveObjs failed | make[3]: *** [linker_unload] Fehler 1 | | *** unexpected failure for linker_unload(normal) | | | Greetings, | Joachim | | -- | Joachim “nomeata” Breitner | mail@joachim-breitner.de • http://www.joachim-breitner.de/ | Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F | Debian Developer: nomeata@debian.org
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... :-/
Hi, Am Mittwoch, den 03.12.2014, 11:18 +0100 schrieb Herbert Valerio Riedel:
On 2014-12-03 at 09:48:58 +0100, Simon Peyton Jones wrote: 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)
and for a failing, it is not. I further narrowed it down to the question of whether gcc passes "--as-needed" to ld by default: If I pass "-optl-Wl,--no-as-needed" to ghc when compiling linker_unload.c, it works there as well. In some releases of Ubuntu, --as-needed is the default¹. Not sure why Herbert does not see this behavior in a recent release (14.04). I’m also not sure about the right fix: Should we just pass -Wl,--no-as-needed to gcc always? But clearly there is a reason for this flag becoming default. Can we set up things so that they work with --as-needed? Greetings, Joachim ¹ https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-November/000783... -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
Have you tried using ld.gold instead? I've run into many issues with
the default ld.bfd recently (none of which seems related to this
issue, but it tells me that weird linker bugs do happen and testing
with another linker may help isolate the root cause).
--
Mathieu Boespflug
Founder at http://tweag.io.
On 3 December 2014 at 14:13, Joachim Breitner
Hi,
Am Mittwoch, den 03.12.2014, 11:18 +0100 schrieb Herbert Valerio Riedel:
On 2014-12-03 at 09:48:58 +0100, Simon Peyton Jones wrote: 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)
and for a failing, it is not.
I further narrowed it down to the question of whether gcc passes "--as-needed" to ld by default: If I pass "-optl-Wl,--no-as-needed" to ghc when compiling linker_unload.c, it works there as well.
In some releases of Ubuntu, --as-needed is the default¹. Not sure why Herbert does not see this behavior in a recent release (14.04).
I’m also not sure about the right fix: Should we just pass -Wl,--no-as-needed to gcc always? But clearly there is a reason for this flag becoming default. Can we set up things so that they work with --as-needed?
Greetings, Joachim
¹ https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-November/000783...
-- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
On 03/12/2014 13:13, Joachim Breitner wrote:
Hi,
Am Mittwoch, den 03.12.2014, 11:18 +0100 schrieb Herbert Valerio Riedel:
On 2014-12-03 at 09:48:58 +0100, Simon Peyton Jones wrote: 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)
and for a failing, it is not.
I further narrowed it down to the question of whether gcc passes "--as-needed" to ld by default: If I pass "-optl-Wl,--no-as-needed" to ghc when compiling linker_unload.c, it works there as well.
In some releases of Ubuntu, --as-needed is the default¹. Not sure why Herbert does not see this behavior in a recent release (14.04).
I’m also not sure about the right fix: Should we just pass -Wl,--no-as-needed to gcc always? But clearly there is a reason for this flag becoming default. Can we set up things so that they work with --as-needed?
No, I don't think we should do that. We should play nicely with however the platform decides it wants to do linking. Cheers, Simon
At a guess, you could try this: --- a/testsuite/tests/rts/Makefile +++ b/testsuite/tests/rts/Makefile @@ -124,7 +124,7 @@ linker_unload: $(RM) Test.o Test.hi "$(TEST_HC)" $(TEST_HC_OPTS) -c Test.hs -v0 # -rtsopts causes a warning - "$(TEST_HC)" $(filter-out -rtsopts, $(TEST_HC_OPTS)) linker_unload.c -o linker_unload -no-hs-main -optc-Werror -debug -optc-g + "$(TEST_HC)" $(filter-out -rtsopts, $(TEST_HC_OPTS)) linker_unload.c -o linker_unload -no-hs-main -optc-Werror -debug -optc-g -lgmp ./linker_unload $(BASE) $(GHC_PRIM) $(INTEGER_GMP) On 03/12/2014 10:18, Herbert Valerio Riedel wrote:
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... :-/ _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Hi, Am Mittwoch, den 03.12.2014, 13:22 +0000 schrieb Simon Marlow:
At a guess, you could try this:
--- a/testsuite/tests/rts/Makefile +++ b/testsuite/tests/rts/Makefile @@ -124,7 +124,7 @@ linker_unload: $(RM) Test.o Test.hi "$(TEST_HC)" $(TEST_HC_OPTS) -c Test.hs -v0 # -rtsopts causes a warning - "$(TEST_HC)" $(filter-out -rtsopts, $(TEST_HC_OPTS)) linker_unload.c -o linker_unload -no-hs-main -optc-Werror -debug -optc-g + "$(TEST_HC)" $(filter-out -rtsopts, $(TEST_HC_OPTS)) linker_unload.c -o linker_unload -no-hs-main -optc-Werror -debug -optc-g -lgmp ./linker_unload $(BASE) $(GHC_PRIM) $(INTEGER_GMP)
no, does not help, as -lgmp is already passed to gcc by ghc: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -o linker_unload linker_unload.o -L/data1/ghc-builder/ghc-master/libraries/base/dist-install/build -L/data1/ghc-builder/ghc-master/libraries/integer-gmp2/dist-install/build -L/data1/ghc-builder/ghc-master/libraries/ghc-prim/dist-install/build -L/data1/ghc-builder/ghc-master/rts/dist/build /tmp/ghc26637_1/ghc26637_4.o /tmp/ghc26637_1/ghc26637_6.o -Wl,-u,ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,base_GHCziPtr_Ptr_static_info -Wl,-u,ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,base_GHCziInt_I8zh_static_info -Wl,-u,base_GHCziInt_I16zh_static_info -Wl,-u,base_GHCziInt_I32zh_static_info -Wl,-u,base_GHCziInt_I64zh_static_info -Wl,-u,base_GHCziWord_W8zh_static_info -Wl,-u,base_GHCziWord_W16zh_static_info -Wl,-u,base_GHCziWord_W32zh_static_info -Wl,-u,base_GHCziWord_W64zh_static_info -Wl,-u,base_GHCziStable_StablePtr_static_info -Wl,-u,ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,base_GHCziPtr_Ptr_con_info -Wl,-u,base_GHCziPtr_FunPtr_con_info -Wl,-u,base_GHCziStable_StablePtr_con_info -Wl,-u,ghczmprim_GHCziTypes_False_closure -Wl,-u,ghczmprim_GHCziTypes_True_closure -Wl,-u,base_GHCziPack_unpackCString_closure -Wl,-u,base_GHCziIOziException_stackOverflow_closure -Wl,-u,base_GHCziIOziException_heapOverflow_closure -Wl,-u,base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,base_GHCziTopHandler_runIO_closure -Wl,-u,base_GHCziTopHandler_runNonIO_closure -Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,base_GHCziConcziSync_runSparks_closure -Wl,-u,base_GHCziConcziSignal_runHandlers_closure -lHSbase_469rOtLAqwTGFEOGWxSUiQ -lHSinteg_21cuTlnn00eFNd4GMrxOMi -lHSghcpr_FgrV6cgh2JHBlbcx1OSlwt -lHSrts_debug -lCffi -lgmp -lm -lrt -ldl '-Wl,--hash-size=31' -Wl,--reduce-memory-overheads but due to --no-needed, and linker_unload indeed not requiring any symbols from gmp, the linker does not link it. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
On 03/12/2014 13:25, Joachim Breitner wrote:
Hi,
Am Mittwoch, den 03.12.2014, 13:22 +0000 schrieb Simon Marlow:
At a guess, you could try this:
--- a/testsuite/tests/rts/Makefile +++ b/testsuite/tests/rts/Makefile @@ -124,7 +124,7 @@ linker_unload: $(RM) Test.o Test.hi "$(TEST_HC)" $(TEST_HC_OPTS) -c Test.hs -v0 # -rtsopts causes a warning - "$(TEST_HC)" $(filter-out -rtsopts, $(TEST_HC_OPTS)) linker_unload.c -o linker_unload -no-hs-main -optc-Werror -debug -optc-g + "$(TEST_HC)" $(filter-out -rtsopts, $(TEST_HC_OPTS)) linker_unload.c -o linker_unload -no-hs-main -optc-Werror -debug -optc-g -lgmp ./linker_unload $(BASE) $(GHC_PRIM) $(INTEGER_GMP)
no, does not help, as -lgmp is already passed to gcc by ghc:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -o linker_unload linker_unload.o -L/data1/ghc-builder/ghc-master/libraries/base/dist-install/build -L/data1/ghc-builder/ghc-master/libraries/integer-gmp2/dist-install/build -L/data1/ghc-builder/ghc-master/libraries/ghc-prim/dist-install/build -L/data1/ghc-builder/ghc-master/rts/dist/build /tmp/ghc26637_1/ghc26637_4.o /tmp/ghc26637_1/ghc26637_6.o -Wl,-u,ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,base_GHCziPtr_Ptr_static_info -Wl,-u,ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,base_GHCziInt_I8zh_static_info -Wl,-u,base_GHCziInt_I16zh_static_info -Wl,-u,base_GHCziInt_I32zh_static_info -Wl,-u,base_GHCziInt_I64zh_static_info -Wl,-u,base_GHCziWord_W8zh_static_info -Wl,-u,base_GHCziWord_W16zh_static_info -Wl,-u,base_GHCziWord_W32zh_static_info -Wl,-u,base_GHCziWord_W64zh_static_info -Wl,-u,base_GHCziStable_StablePtr_static_info -Wl,-u,ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,ghczmp rim_GHCziTypes_Czh_con_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,base_GHCziPtr_Ptr_con_info -Wl,-u,base_GHCziPtr_FunPtr_con_info -Wl,-u,base_GHCziStable_StablePtr_con_info -Wl,-u,ghczmprim_GHCziTypes_False_closure -Wl,-u,ghczmprim_GHCziTypes_True_closure -Wl,-u,base_GHCziPack_unpackCString_closure -Wl,-u,base_GHCziIOziException_stackOverflow_closure -Wl,-u,base_GHCziIOziException_heapOverflow_closure -Wl,-u,base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,base_GHCziTopHandler_runIO_closure -Wl,-u,base_GHCziTopHandler_run NonIO_closure -Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,base_GHCziConcziSync_runSparks_closure -Wl,-u,base_GHCziConcziSignal_runHandlers_closure -lHSbase_469rOtLAqwTGFEOGWxSUiQ -lHSinteg_21cuTlnn00eFNd4GMrxOMi -lHSghcpr_FgrV6cgh2JHBlbcx1OSlwt -lHSrts_debug -lCffi -lgmp -lm -lrt -ldl '-Wl,--hash-size=31' -Wl,--reduce-memory-overheads
but due to --no-needed, and linker_unload indeed not requiring any symbols from gmp, the linker does not link it.
Ok, I was afraid of that. The test needs to be fixed to explicitly dlopen("libgmp"). I'll take a look at it today. Cheers, Simon
Dear Simon, Am Donnerstag, den 04.12.2014, 08:56 +0000 schrieb Simon Marlow:
no, does not help, as -lgmp is already passed to gcc by ghc:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -o linker_unload linker_unload.o -L/data1/ghc-builder/ghc-master/libraries/base/dist-install/build -L/data1/ghc-builder/ghc-master/libraries/integer-gmp2/dist-install/build -L/data1/ghc-builder/ghc-master/libraries/ghc-prim/dist-install/build -L/data1/ghc-builder/ghc-master/rts/dist/build /tmp/ghc26637_1/ghc26637_4.o /tmp/ghc26637_1/ghc26637_6.o -Wl,-u,ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,base_GHCziPtr_Ptr_static_info -Wl,-u,ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,base_GHCziInt_I8zh_static_info -Wl,-u,base_GHCziInt_I16zh_static_info -Wl,-u,base_GHCziInt_I32zh_static_info -Wl,-u,base_GHCziInt_I64zh_static_info -Wl,-u,base_GHCziWord_W8zh_static_info -Wl,-u,base_GHCziWord_W16zh_static_info -Wl,-u,base_GHCziWord_W32zh_static_info -Wl,-u,base_GHCziWord_W64zh_static_info -Wl,-u,base_GHCziStable_StablePtr_static_info -Wl,-u,ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,ghczmp rim_GHCziTypes_Czh_con_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,base_GHCziPtr_Ptr_con_info -Wl,-u,base_GHCziPtr_FunPtr_con_info -Wl,-u,base_GHCziStable_StablePtr_con_info -Wl,-u,ghczmprim_GHCziTypes_False_closure -Wl,-u,ghczmprim_GHCziTypes_True_closure -Wl,-u,base_GHCziPack_unpackCString_closure -Wl,-u,base_GHCziIOziException_stackOverflow_closure -Wl,-u,base_GHCziIOziException_heapOverflow_closure -Wl,-u,base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,base_GHCziTopHandler_runIO_closure -Wl,-u,base_GHCziTopHandler_run NonIO_closure -Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,base_GHCziConcziSync_runSparks_closure -Wl,-u,base_GHCziConcziSignal_runHandlers_closure -lHSbase_469rOtLAqwTGFEOGWxSUiQ -lHSinteg_21cuTlnn00eFNd4GMrxOMi -lHSghcpr_FgrV6cgh2JHBlbcx1OSlwt -lHSrts_debug -lCffi -lgmp -lm -lrt -ldl '-Wl,--hash-size=31' -Wl,--reduce-memory-overheads
but due to --no-needed, and linker_unload indeed not requiring any symbols from gmp, the linker does not link it.
Ok, I was afraid of that. The test needs to be fixed to explicitly dlopen("libgmp"). I'll take a look at it today.
this is still one of the test suite failures showing up at the performance builders. Would you mind having a look? Thanks, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
Hello Simon, On 2014-11-21 at 14:51:55 +0100, Simon Peyton Jones wrote:
I'm getting this for test linker_unload on Linux. I'm sure it's not my fault!
But it makes validate fail
[...]
linker_unload: /5playpen/simonpj/HEAD-2/libraries/integer-gmp2/dist-install/build/libHSinteg_2MbWUstH60IEgCAexOk3v3.a: unknown symbol `__gmpn_rshift' linker_unload: resolveObjs failed make[3]: *** [linker_unload] Error 1
I've tried this in an Ubuntu 12.04.5 LTS/x86_64 environment, but couldn't reproduce it. I'm quite confident that '__gmpn_rshift' is in fact not missing, otherwise you'd get much more failures (and GHC probably wouldn't even build). I also don't think that Ubuntu 12.04's is too old, as it's a GMP 5.0.2 version afaik. Does `TEST=linker_unload` fail deterministically? Would it be possible to update your `sudo apt-get update` & `sudo apt-get dist-upgrade` your Linux environment with the latest bugfixes to Ubuntu 12.04.5? That way we can be sure it's not a subtle bug already fixed upstream... Finally, if that also doesn't help, can you try cloning a fresh tree via git clone --recursive git://ghc.haskell.org/ghc.git <new-folder-name> and invoke ./validate inside <new-folder-name>? HTH, hvr
On 11/25/14 08:18 AM, Herbert Valerio Riedel wrote:
Would it be possible to update your `sudo apt-get update`& `sudo apt-get dist-upgrade` your Linux environment with the latest bugfixes to Ubuntu 12.04.5? That way we can be sure it's not a subtle bug already fixed upstream...
I'm not sure, but IMHO this will lead to upgrade to 14.04.1. What you should use is probably `sudo apt-get update` & `sudo apt-get upgrade` Karel
On 2014-11-25 at 08:23:04 +0100, Karel Gardas wrote:
On 11/25/14 08:18 AM, Herbert Valerio Riedel wrote:
Would it be possible to update your `sudo apt-get update`& `sudo apt-get dist-upgrade` your Linux environment with the latest bugfixes to Ubuntu 12.04.5? That way we can be sure it's not a subtle bug already fixed upstream...
I'm not sure, but IMHO this will lead to upgrade to 14.04.1. What you should use is probably `sudo apt-get update` & `sudo apt-get upgrade`
http://askubuntu.com/questions/215267/will-apt-get-dist-upgrade-upgrade-my-s... TLDR: no, `apt-get dist-upgrade` will not ugrade away from the 12.04.x branch
participants (6)
-
Boespflug, Mathieu -
Herbert Valerio Riedel -
Joachim Breitner -
Karel Gardas -
Simon Marlow -
Simon Peyton Jones