date:20130124

Validate of GHC HEAD freezes on FreeBSD

2013-01-24 Thread 山本和彦

Hello,

The "validate" script against GHC HEAD freezes on FreeBSD 9.1.
After sync-all, I did as follow:


% config_args="--with-iconv-includes=/usr/local/include 
--with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include 
--with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47" CPUS=10 sh 
validate


This stopped quickly due to this problem:
http://hackage.haskell.org/trac/ghc/ticket/7592

Then I executed "validate" with "--no-clean" again.


% config_args="--with-iconv-includes=/usr/local/include 
--with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include 
--with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47" CPUS=10 sh 
validate --no-clean


GHC could be compiled and tests started. But this resulted in:


cd ../../libraries/base/tests && '/usr/home/kazu/work/ghc/bindisttest/install   
dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output 
-no-user-package-db -rtsopts -fno-ghci-history -o qsemn001 qsemn001.hs
>qsemn001.comp.stderr 2>&1
cd ../../libraries/base/tests && ./T5962T5962.run.stdout 
2>T5962.run.stderr
cd ../../libraries/base/tests && ./59435943.run.stdout 
2>5943.run.stderr
cd ../../libraries/base/tests && ./T7034T7034.run.stdout 
2>T7034.run.stderr
cd ../../libraries/base/tests && ./qsem001qsem001.run.stdout 
2>qsem001.run.stderr
cd ../../libraries/base/tests && ./qsemn001qsemn001.run.stdout 
2>qsemn001.run.stderr

Wrong exit code (expected 0 , actual 9 )
Stdout:

Stderr:

*** unexpected failure for Chan002(normal)


And waiting for something forever.

Does anyone understand what happened?

Note that I can build GHC HEAD by typing "gmake" (v3.82 installed by
the ports system) twice.

This is a serious problem for us since we want to merge our code to
GHC HEAD. "validate" against GHC with our code on Linux and Mac passed
so far. But "validate" against even vanilla GHC freezes.

P.S.

On FreeBSD, I applied the following patch for validate since
unused-but-set-variable is not available.

diff --git a/mk/validate-settings.mk b/mk/validate-settings.mk
index 399bf0e..378a3e6 100644
--- a/mk/validate-settings.mk
+++ b/mk/validate-settings.mk
@@ -13,7 +13,7 @@ HADDOCK_DOCS= YES
 # Debian doesn't turn -Werror=unused-but-set-variable on by default, so
 # we turn it on explicitly for consistency with other users
 ifeq "$(GccLT46)" "NO"
-SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable
+#SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable
 # gcc 4.6 gives 3 warning for giveCapabilityToTask not being inlined
 SRC_CC_WARNING_OPTS += -Wno-error=inline
 endif

--Kazu


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

ghc passing -undef to preprocessor and thereby eliminating OS specific defines

2013-01-24 Thread Nathan Hüsken

Hey,

I am trying to adapt some code in the libraries when compiling for
android (i.E. because some things are different on android to other
posix systems).

So in C code I would just do "#ifdef __ANDROID__".
While in the *.h and *.c files it seems to work, it does not work in
*.hs files.
I noted that the preprocessor is run like this:

arm-linux-androideabi-gcc -E -undef -traditional -fno-stack-protector
-DTABLES_NEXT_TO_CODE

The "-undef" parameter is causing the __ANDROID__ define to be removed.
Does it make sense to pass "-undef" to the preprocessor?

Any other Ideas how I could adapt the code for android?

Thanks!
Nathan

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ghc passing -undef to preprocessor and thereby eliminating OS specific defines

2013-01-24 Thread Simon Marlow


On 24/01/13 11:21, Nathan Hüsken wrote:

Hey,

I am trying to adapt some code in the libraries when compiling for
android (i.E. because some things are different on android to other
posix systems).

So in C code I would just do "#ifdef __ANDROID__".
While in the *.h and *.c files it seems to work, it does not work in
*.hs files.
I noted that the preprocessor is run like this:

arm-linux-androideabi-gcc -E -undef -traditional -fno-stack-protector
-DTABLES_NEXT_TO_CODE

The "-undef" parameter is causing the __ANDROID__ define to be removed.
Does it make sense to pass "-undef" to the preprocessor?

Any other Ideas how I could adapt the code for android?


You want to use:

  #ifdef android_HOST_OS

the *_HOST_OS symbol is defined by GHC when it ivokes CPP.

Cheers,
Simon



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

2013-01-24 Thread Nathan Hüsken

Hey,

For me thinks have changed.
With the current ghc HEAD and llvm version 3.2 I am able to do a
registerised build for android!
I have not tested much, but Hello World works.
Regards,
Nathan

On 01/14/2013 06:15 PM, Nathan Hüsken wrote:
> In a different thread (Error building ghc on raspberry pi):
> 
> On 01/08/2013 12:27 PM, Thijs Alkemade wrote:(...)
>>
>> I did eventually finish building stage2, but the final executable
> segfaulted on start.
>> I haven't investigated much why that happened, the days it takes to
> rebuild it just
>> made me give up.
> 
> Was that an registerised or unregisterised build?
> Did anyone succesfully build ghc on an arm system which produces non
> crashing executables?
> 
> I am asking, because I build a arm-linux-androideabi cross compiler, but
> the executables crash.
> Only in an unregisterised build, they work.
> 
> So I wonder if it is a general arm problem or has to do with android.
> 
> Thanks!
> Nathan
> 
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

2013-01-24 Thread Stephen Paul Weber


Somebody claiming to be Nathan Hüsken wrote:

Hey,

For me thinks have changed.
With the current ghc HEAD and llvm version 3.2 I am able to do a
registerised build for android!


Do you think it is specifically the 3.2 that made it work?

--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

2013-01-24 Thread Nathan Hüsken

On 01/24/2013 03:58 PM, Stephen Paul Weber wrote:
> Somebody claiming to be Nathan Hüsken wrote:
>> Hey,
>>
>> For me thinks have changed.
>> With the current ghc HEAD and llvm version 3.2 I am able to do a
>> registerised build for android!
> 
> Do you think it is specifically the 3.2 that made it work?

Yes. With llvm version 3.1 I was only able to get an unregisterised
build to work. Stephen Blackheath found that out, see here:
http://www.haskell.org/pipermail/iphone/2013-January/000212.html

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

2013-01-24 Thread Stephen Paul Weber


Somebody claiming to be Nathan Hüsken wrote:

On 01/24/2013 03:58 PM, Stephen Paul Weber wrote:

Somebody claiming to be Nathan Hüsken wrote:

With the current ghc HEAD and llvm version 3.2 I am able to do a
registerised build for android!

Do you think it is specifically the 3.2 that made it work?


Yes. With llvm version 3.1 I was only able to get an unregisterised
build to work.


Did you have to hack the source ala 
 
?



Stephen Blackheath found that out, see here:
http://www.haskell.org/pipermail/iphone/2013-January/000212.html


From that post, it seems like llvm-3.0 might also work?

--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

2013-01-24 Thread Nathan Hüsken

On 01/24/2013 04:28 PM, Stephen Paul Weber wrote:
> Somebody claiming to be Nathan Hüsken wrote:
>> On 01/24/2013 03:58 PM, Stephen Paul Weber wrote:
>>> Somebody claiming to be Nathan Hüsken wrote:
 With the current ghc HEAD and llvm version 3.2 I am able to do a
 registerised build for android!
>>> Do you think it is specifically the 3.2 that made it work?
>>
>> Yes. With llvm version 3.1 I was only able to get an unregisterised
>> build to work.
> 
> Did you have to hack the source ala
> 
> ?

Not exactly, see the patch here:
http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html
and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs

> 
>> Stephen Blackheath found that out, see here:
>> http://www.haskell.org/pipermail/iphone/2013-January/000212.html
> 
> From that post, it seems like llvm-3.0 might also work?
> 

At the time of that post, ghc did not compile with 3.0 or 3.2.
I have sticked to 3.2, and ghc compiles with it now. I do not know about
3.0.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

2013-01-24 Thread Stephen Paul Weber


Somebody claiming to be Nathan Hüsken wrote:

On 01/24/2013 04:28 PM, Stephen Paul Weber wrote:

Do you think it is specifically the 3.2 that made it work?

Yes. With llvm version 3.1 I was only able to get an unregisterised
build to work.


?


Not exactly, see the patch here:
http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html
and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs


Oh, man, the fact that I don't have that setting for QNX is probably not 
doing me any favours...


How the heck am I supposed to figure out what that string should be? :(

That said... how did you get an unregisterised build to work with an LLVM 
backend?  Everything I've seen in the code implied that the moment you are 
unregisteried, it uses via-C...  Which is what my above patch is primarily 
about.


--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

2013-01-24 Thread Karel Gardas


On 01/24/13 04:50 PM, Stephen Paul Weber wrote:

Somebody claiming to be Nathan Hüsken wrote:

On 01/24/2013 04:28 PM, Stephen Paul Weber wrote:

Do you think it is specifically the 3.2 that made it work?

Yes. With llvm version 3.1 I was only able to get an unregisterised
build to work.



?


Not exactly, see the patch here:
http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html
and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs


Oh, man, the fact that I don't have that setting for QNX is probably not
doing me any favours...


IIRC it's more about optimization, i.e. proper data type alignment.


How the heck am I supposed to figure out what that string should be? :(


Described here: http://llvm.org/docs/LangRef.html#data-layout -- for 
LLVM 3.3. General rule, I would start with what Linux requires and check 
from that.



That said... how did you get an unregisterised build to work with an
LLVM backend? Everything I've seen in the code implied that the moment
you are unregisteried, it uses via-C... Which is what my above patch is
primarily about.


IMHO Nathan is using registerised build. Nathan correct me please if I'm 
wrong as I'd like to also give your Android work a try in the future 
(being Android user myself...)


Karel


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

2013-01-24 Thread Stephen Paul Weber


Somebody claiming to be Stephen Paul Weber wrote:

Somebody claiming to be Nathan Hüsken wrote:

On 01/24/2013 04:28 PM, Stephen Paul Weber wrote:

Do you think it is specifically the 3.2 that made it work?

Yes. With llvm version 3.1 I was only able to get an unregisterised
build to work.


?


Not exactly, see the patch here:
http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html
and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs


Oh, man, the fact that I don't have that setting for QNX is probably 
not doing me any favours...


I tried the following:

diff --git a/compiler/llvmGen/LlvmCodeGen/Ppr.hs 
b/compiler/llvmGen/LlvmCodeGen/Ppr.hs
index 218870a..a583ffc 100644
--- a/compiler/llvmGen/LlvmCodeGen/Ppr.hs
+++ b/compiler/llvmGen/LlvmCodeGen/Ppr.hs
@@ -58,6 +58,9 @@ moduleLayout = sdocWithPlatform $ \platform ->
 Platform { platformArch = ArchARM {}, platformOS = OSLinux } ->
 text "target datalayout = 
\"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32\""
 $+$ text "target triple = \"arm-unknown-linux-gnueabi\""
+Platform { platformArch = ArchARM {}, platformOS = OSQNXNTO } ->
+text "target datalayout = 
\"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32\""
+$+$ text "target triple = \"arm-unknown-nto-qnx8.0.0eabi\""
 _ ->
 -- FIX: Other targets
 empty

Doing a registered build with llvm-3.0 I eventually get:

"inplace/bin/ghc-stage1" -o utils/hsc2hs/dist-install/build/tmp/hsc2hs -static  -H64m -O0 -fllvm-hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist-install/build -iutils/hsc2hs/dist-install/build/autogen -Iutils/hsc2hs/dist-install/build -Iutils/hsc2hs/dist-install/build/autogen -optP-include -optPutils/hsc2hs/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package containers-0.5.0.0 -package directory-1.2.0.1 -package filepath-1.3.0.2 -package process-1.2.0.0  -XHaskell98 -XCPP -XForeignFunctionInterface  -no-user-package-db -rtsopts  -odir utils/hsc2hs/dist-install/build -hidir utils/hsc2hs/dist-install/build -stubdir utils/hsc2hs/dist-install/build -hisuf hi -osuf  o -hcsuf hc   utils/hsc2hs/dist-install/build/Main.o utils/hsc2hs/dist-install/build/HSCParser.o utils/hsc2hs/dist-install/build/DirectCodegen.o utils/hsc2hs/dist-install/build/CrossCodegen.o utils/hsc2hs/dist-install/build/UtilsCodegen.o utils/hsc2hs/dist-install/build/Common.o utils/hsc2hs/dist-install/build/C.o utils/hsc2hs/dist-install/build/Flags.o utils/hsc2hs/dist-install/build/Paths_hsc2hs.o
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/unix/dist-install/build/libHSunix-2.6.1.0.a(Signals.o): In function `c4Uj_info':

ghc23292_0.c:(.text+0x20d4): undefined reference to `__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/unix/dist-install/build/libHSunix-2.6.1.0.a(Signals.o):
 In function `c4XO_info':
ghc23292_0.c:(.text+0x248c): undefined reference to `__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Buffer.o):
 In function `c2Xe_info':
/tmp/ghc20698_0/ghc20698_0.bc:(.text+0x2558): undefined reference to 
`__aeabi_memmove'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Internals.o):
 In function `c7HG_info':
/tmp/ghc21290_0/ghc21290_0.bc:(.text+0x5e70): undefined reference to 
`__aeabi_memmove'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o):
 In function `base_GHCziIOziHandleziText_zdwccall_info':
/tmp/ghc21310_0/ghc21310_0.bc:(.text+0x378): undefined reference to 
`__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o):
 In function `c7s6_info':
/tmp/ghc21310_0/ghc21310_0.bc:(.text+0x4c4): undefined reference to 
`__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o):
 In function `c9cs_info':
/tmp/ghc21310_0/ghc21310_0.bc:(.text+0x7588): undefined reference to 
`__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o):
 In function `c9nS_info':
/tmp/ghc21310_0/ghc21310_0.bc:(.text+0x8318): undefined reference to 
`__aeabi_memcpy'
/tmp/ghc21310_0/ghc21310_0.bc:(.text+0x83e4): undefined reference to 
`__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o):/tmp/ghc21310_0/ghc21310_0.bc:(.text+0xa2ec):
 more undefined references to `__aeabi_memcpy' follow
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Array.o):
 In function `c1Uf_info':
/tmp/ghc20805_0/ghc20805_0.bc:(.text+0x5a8): undefined reference to 
`__aeabi_memmove'
/home/singpolyma/src/ghc-qnx-nto-ar

Re: any successfull ghc registerised builds on arm?

2013-01-24 Thread Nathan Hüsken

On 01/24/2013 04:50 PM, Stephen Paul Weber wrote:
> Somebody claiming to be Nathan Hüsken wrote:
>> On 01/24/2013 04:28 PM, Stephen Paul Weber wrote:
> Do you think it is specifically the 3.2 that made it work?
 Yes. With llvm version 3.1 I was only able to get an unregisterised
 build to work.
>>> 
>>>
>>> ?
>>
>> Not exactly, see the patch here:
>> http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html
>> and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs
> 
> Oh, man, the fact that I don't have that setting for QNX is probably not
> doing me any favours...
> 
> How the heck am I supposed to figure out what that string should be? :(

Do you mean the data layout? Actually, I have to admit I just copied it
from arm linux.

> 
> That said... how did you get an unregisterised build to work with an
> LLVM backend?  Everything I've seen in the code implied that the moment
> you are unregisteried, it uses via-C...  Which is what my above patch is
> primarily about.
> 

I ... it just worked :). I passed --enable-unregistered to configure and
that did the trick. During building it always said "via-C", but it worked.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

2013-01-24 Thread Nathan Hüsken

On 01/24/2013 05:04 PM, Karel Gardas wrote:
> On 01/24/13 04:50 PM, Stephen Paul Weber wrote:
>> Somebody claiming to be Nathan Hüsken wrote:
>>> On 01/24/2013 04:28 PM, Stephen Paul Weber wrote:
>> Do you think it is specifically the 3.2 that made it work?
> Yes. With llvm version 3.1 I was only able to get an unregisterised
> build to work.
 


 ?
>>>
>>> Not exactly, see the patch here:
>>> http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html
>>> and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs
>>
>> Oh, man, the fact that I don't have that setting for QNX is probably not
>> doing me any favours...
> 
> IIRC it's more about optimization, i.e. proper data type alignment.
> 
>> How the heck am I supposed to figure out what that string should be? :(
> 
> Described here: http://llvm.org/docs/LangRef.html#data-layout -- for
> LLVM 3.3. General rule, I would start with what Linux requires and check
> from that.
> 
>> That said... how did you get an unregisterised build to work with an
>> LLVM backend? Everything I've seen in the code implied that the moment
>> you are unregisteried, it uses via-C... Which is what my above patch is
>> primarily about.
> 
> IMHO Nathan is using registerised build. Nathan correct me please if I'm
> wrong as I'd like to also give your Android work a try in the future
> (being Android user myself...)

Yes, that is correct. registerised with llvm 3.2.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

2013-01-24 Thread Nathan Hüsken

On 01/24/2013 05:51 PM, Stephen Paul Weber wrote:
(...)
> 
> So... it can't find memcpy for some reason?
> 
> I'm about to try with llvm-3.2 to see if that's different.
> 

I had similar problems with mkfifo. I believe the reason was, that in
the android nkd mkfifo is inlined.

The solution for me was to wrap mkfifo (in a function I called __mkfifo)
and used that one from the ffi instead.

But the symbol not found is __aeabi_memcpy, not memcpy itself ...
I can not find __aeabi_memcpy in the ghc source ...
Maybe it is not linking some required library?

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

2013-01-24 Thread Stephen Paul Weber


Somebody claiming to be Nathan Hüsken wrote:

On 01/24/2013 05:51 PM, Stephen Paul Weber wrote:
(...)


So... it can't find memcpy for some reason?

I'm about to try with llvm-3.2 to see if that's different.



The solution for me was to wrap mkfifo (in a function I called __mkfifo)
and used that one from the ffi instead.


Right, I see things around on the web about people doing similar stuff.


But the symbol not found is __aeabi_memcpy, not memcpy itself ...
I can not find __aeabi_memcpy in the ghc source ...
Maybe it is not linking some required library?


I'm not sure.  Most curious is that this has not come up before in any of my 
other ARM-build attempts (which produced less-than-working code, but 
suceeded in compiling).


--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

2013-01-24 Thread Karel Gardas


On 01/24/13 05:51 PM, Stephen Paul Weber wrote:

Doing a registered build with llvm-3.0 I eventually get:

"inplace/bin/ghc-stage1" -o utils/hsc2hs/dist-install/build/tmp/hsc2hs
-static -H64m -O0 -fllvm -hide-all-packages -i -iutils/hsc2hs/.
-iutils/hsc2hs/dist-install/build
-iutils/hsc2hs/dist-install/build/autogen
-Iutils/hsc2hs/dist-install/build
-Iutils/hsc2hs/dist-install/build/autogen -optP-include
-optPutils/hsc2hs/dist-install/build/autogen/cabal_macros.h -package
base-4.7.0.0 -package containers-0.5.0.0 -package directory-1.2.0.1
-package filepath-1.3.0.2 -package process-1.2.0.0 -XHaskell98 -XCPP
-XForeignFunctionInterface -no-user-package-db -rtsopts -odir
utils/hsc2hs/dist-install/build -hidir utils/hsc2hs/dist-install/build
-stubdir utils/hsc2hs/dist-install/build -hisuf hi -osuf o -hcsuf hc
utils/hsc2hs/dist-install/build/Main.o
utils/hsc2hs/dist-install/build/HSCParser.o
utils/hsc2hs/dist-install/build/DirectCodegen.o
utils/hsc2hs/dist-install/build/CrossCodegen.o
utils/hsc2hs/dist-install/build/UtilsCodegen.o
utils/hsc2hs/dist-install/build/Common.o
utils/hsc2hs/dist-install/build/C.o
utils/hsc2hs/dist-install/build/Flags.o
utils/hsc2hs/dist-install/build/Paths_hsc2hs.o
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/unix/dist-install/build/libHSunix-2.6.1.0.a(Signals.o):
In function `c4Uj_info':
ghc23292_0.c:(.text+0x20d4): undefined reference to `__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/unix/dist-install/build/libHSunix-2.6.1.0.a(Signals.o):
In function `c4XO_info':
ghc23292_0.c:(.text+0x248c): undefined reference to `__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Buffer.o):
In function `c2Xe_info':
/tmp/ghc20698_0/ghc20698_0.bc:(.text+0x2558): undefined reference to
`__aeabi_memmove'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Internals.o):
In function `c7HG_info':
/tmp/ghc21290_0/ghc21290_0.bc:(.text+0x5e70): undefined reference to
`__aeabi_memmove'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o):
In function `base_GHCziIOziHandleziText_zdwccall_info':
/tmp/ghc21310_0/ghc21310_0.bc:(.text+0x378): undefined reference to
`__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o):
In function `c7s6_info':
/tmp/ghc21310_0/ghc21310_0.bc:(.text+0x4c4): undefined reference to
`__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o):
In function `c9cs_info':
/tmp/ghc21310_0/ghc21310_0.bc:(.text+0x7588): undefined reference to
`__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o):
In function `c9nS_info':
/tmp/ghc21310_0/ghc21310_0.bc:(.text+0x8318): undefined reference to
`__aeabi_memcpy'
/tmp/ghc21310_0/ghc21310_0.bc:(.text+0x83e4): undefined reference to
`__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o):/tmp/ghc21310_0/ghc21310_0.bc:(.text+0xa2ec):
more undefined references to `__aeabi_memcpy' follow
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Array.o):
In function `c1Uf_info':
/tmp/ghc20805_0/ghc20805_0.bc:(.text+0x5a8): undefined reference to
`__aeabi_memmove'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Array.o):
In function `c1Wm_info':
/tmp/ghc20805_0/ghc20805_0.bc:(.text+0x7dc): undefined reference to
`__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Utils.o):
In function `c205_info':
/tmp/ghc20795_0/ghc20795_0.bc:(.text+0xcf8): undefined reference to
`__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Utils.o):
In function `c21k_info':
/tmp/ghc20795_0/ghc20795_0.bc:(.text+0xe30): undefined reference to
`__aeabi_memmove'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Internals.o):
In function `c89F_info':
ghc21121_0.c:(.text+0x7a20): undefined reference to `__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Array.o):
In function `c4uI_info':
/tmp/ghc21061_0/ghc21061_0.bc:(.text+0x23e0): undefined reference to
`__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Array.o):
In function `c4DF_info':
/tmp/ghc21061_0/ghc21061_0.bc:(.text+0x2e28): undefined reference to
`__aeabi_memmove'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Array.o):
In function `c4Qo_info':
/tmp/ghc21061_0/ghc21061_0.bc:(.text+0x33cc): undefined reference to
`__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Array.o):
In function `c59t_info':
/tm

Re: any successfull ghc registerised builds on arm?

2013-01-24 Thread Stephen Paul Weber


Somebody claiming to be Stephen Paul Weber wrote:

Somebody claiming to be Nathan Hüsken wrote:

But the symbol not found is __aeabi_memcpy, not memcpy itself ...
I can not find __aeabi_memcpy in the ghc source ...
Maybe it is not linking some required library?


I'm not sure.  Most curious is that this has not come up before in 
any of my other ARM-build attempts (which produced less-than-working 
code, but suceeded in compiling).


This seems to be a general ARM thing: 
 
... so not sure why I'm getting it and no one else is.


--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

2013-01-24 Thread Stephen Paul Weber


Somebody claiming to be Karel Gardas wrote:

On 01/24/13 05:51 PM, Stephen Paul Weber wrote:

Doing a registered build with llvm-3.0 I eventually get:
In function `c58Y_info':
/tmp/ghc21061_0/ghc21061_0.bc:(.text+0x42d4): undefined reference to
`__aeabi_memcpy'
collect2: ld returned 1 exit status
make[1]: *** [utils/hsc2hs/dist-install/build/tmp/hsc2hs] Error 1
make: *** [all] Error 2

This is purely linker issue.  Somehow you link with different set of 
libraries probably.  Anyway it looks like: 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3934.html 
-- this function is part of common ARM EABI so it should be implemented by 
your C compiler tool-chain. You just need to find out where it is and how 
you may use it.


So, not sure on the right solution, but when I add   -lcapsthen the 
linker errors go away and I can build executables.  Unfortunately, when I 
try to run any of them on a device, I get a segfault, just as I always did 
with registerised cross-builds for ARM... this with both llvm-3.0 and 
llvm-3.2


:(

--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

2013-01-24 Thread Karel Gardas


On 01/24/13 06:51 PM, Stephen Paul Weber wrote:

Somebody claiming to be Stephen Paul Weber wrote:

Somebody claiming to be Nathan Hüsken wrote:

But the symbol not found is __aeabi_memcpy, not memcpy itself ...
I can not find __aeabi_memcpy in the ghc source ...
Maybe it is not linking some required library?


I'm not sure. Most curious is that this has not come up before in any
of my other ARM-build attempts (which produced less-than-working code,
but suceeded in compiling).


This seems to be a general ARM thing:

... so not sure why I'm getting it and no one else is.


Copy your last ghc-stage1 invocation step, add "-v -keep-tmp-files" and 
see what it'll execute for you. At least you should see libraries which 
are going into the link process.


Then write C hello world, compile and link it and see what's going 
inside linking and compare with ghc. I guess some lib will be missing in 
case of ghc linking phase so you'll need to add it either into 
mk/build.mk appropriate option (E.g. -optl-l) or just hack 
DynFlags.hs to include this for you.


Karel



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

2013-01-24 Thread Nathan Hüsken

On 01/24/2013 07:00 PM, Stephen Paul Weber wrote:
> Somebody claiming to be Karel Gardas wrote:
>> On 01/24/13 05:51 PM, Stephen Paul Weber wrote:
>>> Doing a registered build with llvm-3.0 I eventually get:
>>> In function `c58Y_info':
>>> /tmp/ghc21061_0/ghc21061_0.bc:(.text+0x42d4): undefined reference to
>>> `__aeabi_memcpy'
>>> collect2: ld returned 1 exit status
>>> make[1]: *** [utils/hsc2hs/dist-install/build/tmp/hsc2hs] Error 1
>>> make: *** [all] Error 2
>>>
>> This is purely linker issue.  Somehow you link with different set of
>> libraries probably.  Anyway it looks like:
>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3934.html
>> -- this function is part of common ARM EABI so it should be
>> implemented by your C compiler tool-chain. You just need to find out
>> where it is and how you may use it.
> 
> So, not sure on the right solution, but when I add   -lcapsthen the
> linker errors go away and I can build executables.  Unfortunately, when
> I try to run any of them on a device, I get a segfault, just as I always
> did with registerised cross-builds for ARM... this with both llvm-3.0
> and llvm-3.2
> 
> :(
> 
Can you run it in gdb and loock what the backtrace looks like?


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

2013-01-24 Thread Stephen Paul Weber


Somebody claiming to be Nathan Hüsken wrote:

On 01/24/2013 07:00 PM, Stephen Paul Weber wrote:

Somebody claiming to be Karel Gardas wrote:

On 01/24/13 05:51 PM, Stephen Paul Weber wrote:

:(


Can you run it in gdb and loock what the backtrace looks like?


I can maybe get a core file and load it into gdb.  I may try that soon.

--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

2013-01-24 Thread Stephen Paul Weber


Somebody claiming to be Nathan Hüsken wrote:

On 01/24/2013 07:00 PM, Stephen Paul Weber wrote:

Somebody claiming to be Karel Gardas wrote:

On 01/24/13 05:51 PM, Stephen Paul Weber wrote:

So, not sure on the right solution, but when I add   -lcapsthen the
linker errors go away and I can build executables.  Unfortunately, when
I try to run any of them on a device, I get a segfault, just as I always
did with registerised cross-builds for ARM... this with both llvm-3.0
and llvm-3.2

:(


Can you run it in gdb and loock what the backtrace looks like?


[New pid 14037182 tid 1]
Program terminated with signal 11, Segmentation fault.
#0  0x08502000 in ?? ()
(gdb) bt
#0  0x08502000 in ?? ()
#1  0x082ce4c4 in ?? ()
#2  0x082ce4c4 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) 


--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

2013-01-24 Thread Nathan Hüsken

On 01/24/2013 07:26 PM, Stephen Paul Weber wrote:
> Somebody claiming to be Nathan Hüsken wrote:
>> On 01/24/2013 07:00 PM, Stephen Paul Weber wrote:
>>> Somebody claiming to be Karel Gardas wrote:
 On 01/24/13 05:51 PM, Stephen Paul Weber wrote:
>>> So, not sure on the right solution, but when I add   -lcapsthen the
>>> linker errors go away and I can build executables.  Unfortunately, when
>>> I try to run any of them on a device, I get a segfault, just as I always
>>> did with registerised cross-builds for ARM... this with both llvm-3.0
>>> and llvm-3.2
>>>
>>> :(
>>>
>> Can you run it in gdb and loock what the backtrace looks like?
> 
> [New pid 14037182 tid 1]
> Program terminated with signal 11, Segmentation fault.
> #0  0x08502000 in ?? ()
> (gdb) bt
> #0  0x08502000 in ?? ()
> #1  0x082ce4c4 in ?? ()
> #2  0x082ce4c4 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)

Not very informative :).
Did you compile with -debug?
I remember I got a stack trace with gdb like this (when doing remote
debugging) and got it cleaned up by loading the exectuable with "file".
Maybe you have to do something like that to?


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

2013-01-24 Thread David Terei

Hi all,

Can people please file bugs about these issues when they are confirmed
to some degree? Lots of ARM & LLVM stuff seems to just be floating
around mailing lists much higher chance of me or someone else
fixing if there are filed bug reports with test cases and/or patches
attached.

Austin and I also fixed a couple of LLVM related issues in the last 2
days or so, so hopefully that solved some of these.

Top level bugs to link to when filing other bugs please:

* GHC ARM support: http://hackage.haskell.org/trac/ghc/ticket/7623
* LLVM Cross compilation: http://hackage.haskell.org/trac/ghc/ticket/7610
* LLVM unregisterised issues: http://hackage.haskell.org/trac/ghc/ticket/7622
* LLVM bootstrap issues: http://hackage.haskell.org/trac/ghc/ticket/7590

Cheers,
David

On 24 January 2013 10:28, Nathan Hüsken  wrote:
> On 01/24/2013 07:26 PM, Stephen Paul Weber wrote:
>> Somebody claiming to be Nathan Hüsken wrote:
>>> On 01/24/2013 07:00 PM, Stephen Paul Weber wrote:
 Somebody claiming to be Karel Gardas wrote:
> On 01/24/13 05:51 PM, Stephen Paul Weber wrote:
 So, not sure on the right solution, but when I add   -lcapsthen the
 linker errors go away and I can build executables.  Unfortunately, when
 I try to run any of them on a device, I get a segfault, just as I always
 did with registerised cross-builds for ARM... this with both llvm-3.0
 and llvm-3.2

 :(

>>> Can you run it in gdb and loock what the backtrace looks like?
>>
>> [New pid 14037182 tid 1]
>> Program terminated with signal 11, Segmentation fault.
>> #0  0x08502000 in ?? ()
>> (gdb) bt
>> #0  0x08502000 in ?? ()
>> #1  0x082ce4c4 in ?? ()
>> #2  0x082ce4c4 in ?? ()
>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>> (gdb)
>
> Not very informative :).
> Did you compile with -debug?
> I remember I got a stack trace with gdb like this (when doing remote
> debugging) and got it cleaned up by loading the exectuable with "file".
> Maybe you have to do something like that to?
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

2013-01-24 Thread Stephen Paul Weber


Somebody claiming to be Nathan Hüsken wrote:

On 01/24/2013 07:26 PM, Stephen Paul Weber wrote:

Somebody claiming to be Nathan Hüsken wrote:

Can you run it in gdb and loock what the backtrace looks like?

Did you compile with -debug?
I remember I got a stack trace with gdb like this (when doing remote
debugging) and got it cleaned up by loading the exectuable with "file".
Maybe you have to do something like that to?


$ ntoarm-gdb --core=Main.core Main
... copyright and such ...

[New pid 14336138 tid 1]

warning: .dynamic section for 
"/home/singpolyma/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/libEGL.so.1" 
is not at the expected address (wrong library or version mismatch?)

warning: .dynamic section for 
"/home/singpolyma/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/libGLESv2.so.1"
 is not at the expected address (wrong library or version mismatch?)
Program terminated with signal 11, Segmentation fault.
#0  0x08402000 in ?? ()
(gdb) bt
#0  0x08402000 in ?? ()
#1  0x082de978 in stg_ap_p_fast ()
#2  0x082de978 in stg_ap_p_fast ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Validate of GHC HEAD freezes on FreeBSD

2013-01-24 Thread 山本和彦

Hi,

I confirmed that testsuite/timeout/install-inplace/bin/timeout.py does
not receive SIGALRM, so it is waiting forever.

Any suggestions to fix this?

--Kazu

> Hello,
> 
> The "validate" script against GHC HEAD freezes on FreeBSD 9.1.
> After sync-all, I did as follow:
> 
> 
> % config_args="--with-iconv-includes=/usr/local/include 
> --with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include 
> --with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47" CPUS=10 
> sh validate
> 
> 
> This stopped quickly due to this problem:
>   http://hackage.haskell.org/trac/ghc/ticket/7592
> 
> Then I executed "validate" with "--no-clean" again.
> 
> 
> % config_args="--with-iconv-includes=/usr/local/include 
> --with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include 
> --with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47" CPUS=10 
> sh validate --no-clean
> 
> 
> GHC could be compiled and tests started. But this resulted in:
> 
> 
> cd ../../libraries/base/tests && '/usr/home/kazu/work/ghc/bindisttest/install 
>   dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output 
> -no-user-package-db -rtsopts -fno-ghci-history -o qsemn001 qsemn001.hs
> >qsemn001.comp.stderr 2>&1
> cd ../../libraries/base/tests && ./T5962T5962.run.stdout 
> 2>T5962.run.stderr
> cd ../../libraries/base/tests && ./59435943.run.stdout 
> 2>5943.run.stderr
> cd ../../libraries/base/tests && ./T7034T7034.run.stdout 
> 2>T7034.run.stderr
> cd ../../libraries/base/tests && ./qsem001qsem001.run.stdout 
> 2>qsem001.run.stderr
> cd ../../libraries/base/tests && ./qsemn001 >qsemn001.run.stdout 2>qsemn001.run.stderr
> 
> Wrong exit code (expected 0 , actual 9 )
> Stdout:
> 
> Stderr:
> 
> *** unexpected failure for Chan002(normal)
> 
> 
> And waiting for something forever.
> 
> Does anyone understand what happened?
> 
> Note that I can build GHC HEAD by typing "gmake" (v3.82 installed by
> the ports system) twice.
> 
> This is a serious problem for us since we want to merge our code to
> GHC HEAD. "validate" against GHC with our code on Linux and Mac passed
> so far. But "validate" against even vanilla GHC freezes.
> 
> P.S.
> 
> On FreeBSD, I applied the following patch for validate since
> unused-but-set-variable is not available.
> 
> diff --git a/mk/validate-settings.mk b/mk/validate-settings.mk
> index 399bf0e..378a3e6 100644
> --- a/mk/validate-settings.mk
> +++ b/mk/validate-settings.mk
> @@ -13,7 +13,7 @@ HADDOCK_DOCS= YES
>  # Debian doesn't turn -Werror=unused-but-set-variable on by default, so
>  # we turn it on explicitly for consistency with other users
>  ifeq "$(GccLT46)" "NO"
> -SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable
> +#SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable
>  # gcc 4.6 gives 3 warning for giveCapabilityToTask not being inlined
>  SRC_CC_WARNING_OPTS += -Wno-error=inline
>  endif
> 
> --Kazu
> 
> 
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Validate of GHC HEAD freezes on FreeBSD

2013-01-24 Thread 山本和彦

OK. I found an alternative timeout command written in Haskell.  And
insert "unblockSignals fullSignalSet" to it. Now "validate" can
finish.

I guess that one process (possibly GNU make) set signal mask and its
children inherit it. What is a right solution for this?

--Kazu

> I confirmed that testsuite/timeout/install-inplace/bin/timeout.py does
> not receive SIGALRM, so it is waiting forever.
> 
> Any suggestions to fix this?
> 
> --Kazu
> 
>> Hello,
>> 
>> The "validate" script against GHC HEAD freezes on FreeBSD 9.1.
>> After sync-all, I did as follow:
>> 
>> 
>> % config_args="--with-iconv-includes=/usr/local/include 
>> --with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include 
>> --with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47" CPUS=10 
>> sh validate
>> 
>> 
>> This stopped quickly due to this problem:
>>  http://hackage.haskell.org/trac/ghc/ticket/7592
>> 
>> Then I executed "validate" with "--no-clean" again.
>> 
>> 
>> % config_args="--with-iconv-includes=/usr/local/include 
>> --with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include 
>> --with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47" CPUS=10 
>> sh validate --no-clean
>> 
>> 
>> GHC could be compiled and tests started. But this resulted in:
>> 
>> 
>> cd ../../libraries/base/tests && 
>> '/usr/home/kazu/work/ghc/bindisttest/install   dir/bin/ghc' -fforce-recomp 
>> -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts 
>> -fno-ghci-history -o qsemn001 qsemn001.hs>qsemn001.comp.stderr 2>&1
>> cd ../../libraries/base/tests && ./T5962T5962.run.stdout 
>> 2>T5962.run.stderr
>> cd ../../libraries/base/tests && ./59435943.run.stdout 
>> 2>5943.run.stderr
>> cd ../../libraries/base/tests && ./T7034T7034.run.stdout 
>> 2>T7034.run.stderr
>> cd ../../libraries/base/tests && ./qsem001qsem001.run.stdout 
>> 2>qsem001.run.stderr
>> cd ../../libraries/base/tests && ./qsemn001> >qsemn001.run.stdout 2>qsemn001.run.stderr
>> 
>> Wrong exit code (expected 0 , actual 9 )
>> Stdout:
>> 
>> Stderr:
>> 
>> *** unexpected failure for Chan002(normal)
>> 
>> 
>> And waiting for something forever.
>> 
>> Does anyone understand what happened?
>> 
>> Note that I can build GHC HEAD by typing "gmake" (v3.82 installed by
>> the ports system) twice.
>> 
>> This is a serious problem for us since we want to merge our code to
>> GHC HEAD. "validate" against GHC with our code on Linux and Mac passed
>> so far. But "validate" against even vanilla GHC freezes.
>> 
>> P.S.
>> 
>> On FreeBSD, I applied the following patch for validate since
>> unused-but-set-variable is not available.
>> 
>> diff --git a/mk/validate-settings.mk b/mk/validate-settings.mk
>> index 399bf0e..378a3e6 100644
>> --- a/mk/validate-settings.mk
>> +++ b/mk/validate-settings.mk
>> @@ -13,7 +13,7 @@ HADDOCK_DOCS= YES
>>  # Debian doesn't turn -Werror=unused-but-set-variable on by default, so
>>  # we turn it on explicitly for consistency with other users
>>  ifeq "$(GccLT46)" "NO"
>> -SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable
>> +#SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable
>>  # gcc 4.6 gives 3 warning for giveCapabilityToTask not being inlined
>>  SRC_CC_WARNING_OPTS += -Wno-error=inline
>>  endif
>> 
>> --Kazu
>> 
>> 
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Validate of GHC HEAD freezes on FreeBSD

ghc passing -undef to preprocessor and thereby eliminating OS specific defines

Re: ghc passing -undef to preprocessor and thereby eliminating OS specific defines

Re: any successfull ghc registerised builds on arm?

Re: any successfull ghc registerised builds on arm?

Re: any successfull ghc registerised builds on arm?

Re: any successfull ghc registerised builds on arm?

Re: any successfull ghc registerised builds on arm?

Re: any successfull ghc registerised builds on arm?

Re: any successfull ghc registerised builds on arm?

Re: any successfull ghc registerised builds on arm?

Re: any successfull ghc registerised builds on arm?

Re: any successfull ghc registerised builds on arm?

Re: any successfull ghc registerised builds on arm?

Re: any successfull ghc registerised builds on arm?

Re: any successfull ghc registerised builds on arm?

Re: any successfull ghc registerised builds on arm?

Re: any successfull ghc registerised builds on arm?

Re: any successfull ghc registerised builds on arm?

Re: any successfull ghc registerised builds on arm?

Re: any successfull ghc registerised builds on arm?

Re: any successfull ghc registerised builds on arm?

Re: any successfull ghc registerised builds on arm?

Re: any successfull ghc registerised builds on arm?

Re: any successfull ghc registerised builds on arm?

Re: Validate of GHC HEAD freezes on FreeBSD

Re: Validate of GHC HEAD freezes on FreeBSD

27 matches

Site Navigation

Mail list logo

Footer information