Re: linker_unload
Dear Simon, Am Donnerstag, den 04.12.2014, 08:56 + 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 m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: linker_unload
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 = (0x7fff20f6c000) libgmp.so.10 = /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x7f83c5bbb000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f83c58b5000) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f83c56ac000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f83c54a8000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f83c50e3000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f83c4ec4000) /lib64/ld-linux-x86-64.so.2 (0x7f83c5e76000) 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
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 m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: linker_unload
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 m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: linker_unload
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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: linker_unload
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-boun...@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 |m...@joachim-breitner.de • http://www.joachim-breitner.de/ |Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F |Debian Developer: nome...@debian.org ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: linker_unload
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 = (0x7fff20f6c000)
libgmp.so.10 = /usr/lib/x86_64-linux-gnu/libgmp.so.10
(0x7f83c5bbb000)
libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f83c58b5000)
librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f83c56ac000)
libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f83c54a8000)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f83c50e3000)
libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f83c4ec4000)
/lib64/ld-linux-x86-64.so.2 (0x7f83c5e76000)
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
Re: linker_unload
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 m...@joachim-breitner.de 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 = (0x7fff20f6c000) libgmp.so.10 = /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x7f83c5bbb000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f83c58b5000) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f83c56ac000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f83c54a8000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f83c50e3000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f83c4ec4000) /lib64/ld-linux-x86-64.so.2 (0x7f83c5e76000) 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.html -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: linker_unload
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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: linker_unload
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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: linker_unload
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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: linker_unload
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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: linker_unload
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-system-to-newer-version TLDR: no, `apt-get dist-upgrade` will not ugrade away from the 12.04.x branch ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: linker_unload validate related issue (how to duplicate that?).
Hi Edward, thanks for dealing with this. I've found a little bit different reason. validate runs with ghc installed in bindisttest/install dir/ and the tests invokes ghc-pkg to get gmp library path. The dir above is then returned quoted: ./install dir/. What I did in my linker_unload fix is to cut -d ' ' -f 1-1 IIRC which returned /install and nothing more (quotes missing). The shell then complains with the message below. Anyway, this is already fixed by reverting the patch and I already validated and pushed another version of it which correctly use head -1 to get the intended first directory name... Hopefully this time I've not broken anything. Thanks! Karel On 08/ 6/14 12:04 PM, Edward Z. Yang wrote: Austin and I chatted about it, and it's probably because the test is not creating ghcconfig.h early enough. I haven't looked further on how to fix it though. Edward Excerpts from Karel Gardas's message of 2014-08-06 10:16:20 +0100: Folks, I've noted that validate is failing on Linux recently due to issue in linker_unload. As I've submitted some patch to this test case recently which fixes this on Solaris I'm kind of curious if I broke it or not. Anyway, strange thing is: when I configure ghc and run the test by (g)make TEST=linker_unload on both Linux and Solaris I get no failure. When I validate on Linux (validate is not working on Solaris yet), then I get failure in linker_unload: Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: /bin/sh: 1: Syntax error: Unterminated quoted string make[3]: *** [linker_unload] Error 2 *** unexpected failure for linker_unload(normal) when I try to run: cd testsuite make TEST=linker_unload inside this validation tree I again get no failure in this test: [...] = linker_unload(normal) 2522 of 4082 [0, 0, 0] cd ./rts $MAKE -s --no-print-directory linker_unload/dev/null linker_unload.run.stdout 2linker_unload.run.stderr OVERALL SUMMARY for test run started at Wed Aug 6 10:55:17 2014 CEST 0:00:08 spent to go through 4082 total tests, which gave rise to 13459 test cases, of which 13458 were skipped 0 had missing libraries 1 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 0 unexpected failures make[1]: Leaving directory `/home/karel/src/validate-test/testsuite/tests' I've also noted that this test case fails on Solaris builders with strange error: = linker_unload(normal) 170 of 4082 [0, 0, 1] cd ./rts $MAKE -s --no-print-directory linker_unload/dev/null linker_unload.run.stdout 2linker_unload.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: linker_unload: internal error: loadObj: can't read `/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/bindisttest/install/libHSinteg_BcPVjqcazPNGsNFG4agFty.a' (GHC version 7.9.20140806 for i386_unknown_solaris2) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug gmake[3]: *** [linker_unload] Abort (core dumped) So the question is: why validate fails and why builder fails on this particular test and why my common testing on both Solaris and Linux is not able to duplicate the issue? What's so different between validate and builders and between my common: perl boot; ./configuresome params; gmake -j12; cd testsuite; gmake THREADS=12 fast ? Thanks! Karel ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: linker_unload validate related issue (how to duplicate that?).
Austin and I chatted about it, and it's probably because the test is not creating ghcconfig.h early enough. I haven't looked further on how to fix it though. Edward Excerpts from Karel Gardas's message of 2014-08-06 10:16:20 +0100: Folks, I've noted that validate is failing on Linux recently due to issue in linker_unload. As I've submitted some patch to this test case recently which fixes this on Solaris I'm kind of curious if I broke it or not. Anyway, strange thing is: when I configure ghc and run the test by (g)make TEST=linker_unload on both Linux and Solaris I get no failure. When I validate on Linux (validate is not working on Solaris yet), then I get failure in linker_unload: Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: /bin/sh: 1: Syntax error: Unterminated quoted string make[3]: *** [linker_unload] Error 2 *** unexpected failure for linker_unload(normal) when I try to run: cd testsuite make TEST=linker_unload inside this validation tree I again get no failure in this test: [...] = linker_unload(normal) 2522 of 4082 [0, 0, 0] cd ./rts $MAKE -s --no-print-directory linker_unload/dev/null linker_unload.run.stdout 2linker_unload.run.stderr OVERALL SUMMARY for test run started at Wed Aug 6 10:55:17 2014 CEST 0:00:08 spent to go through 4082 total tests, which gave rise to 13459 test cases, of which 13458 were skipped 0 had missing libraries 1 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 0 unexpected failures make[1]: Leaving directory `/home/karel/src/validate-test/testsuite/tests' I've also noted that this test case fails on Solaris builders with strange error: = linker_unload(normal) 170 of 4082 [0, 0, 1] cd ./rts $MAKE -s --no-print-directory linker_unload /dev/null linker_unload.run.stdout 2linker_unload.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: linker_unload: internal error: loadObj: can't read `/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/bindisttest/install/libHSinteg_BcPVjqcazPNGsNFG4agFty.a' (GHC version 7.9.20140806 for i386_unknown_solaris2) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug gmake[3]: *** [linker_unload] Abort (core dumped) So the question is: why validate fails and why builder fails on this particular test and why my common testing on both Solaris and Linux is not able to duplicate the issue? What's so different between validate and builders and between my common: perl boot; ./configure some params; gmake -j12; cd testsuite; gmake THREADS=12 fast ? Thanks! Karel ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: linker_unload validate related issue (how to duplicate that?).
Just for the record validate fails since it is using ghc installed into bindisttest/install dir/ subdirectory. The spaces here are really nasty test as my fix to linker_unload has not counted with the possibility of having ghc installed in such location (cut -d ' ' ... does bad thing in this case). So yes, that was me who broke validate but this should be already fixed by revert of problematic patch. Sorry for that, Karel On 08/ 6/14 11:16 AM, Karel Gardas wrote: So the question is: why validate fails and why builder fails on this particular test and why my common testing on both Solaris and Linux is not able to duplicate the issue? What's so different between validate and builders and between my common: perl boot; ./configure some params; gmake -j12; cd testsuite; gmake THREADS=12 fast ? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
