[PATCH] (haskeline) Include termios.h on android
Hey, This patch is for libraries/haskeline. On android, winsize is defined in termios.h and therefor termios.h must be included. From a081ad57f161f056f7e4c0bd8907de8bb24efa04 Mon Sep 17 00:00:00 2001 From: Nathan nathan.hues...@posteo.de Date: Thu, 24 Jan 2013 15:30:15 +0100 Subject: [PATCH] Include termios.h on android because winsize is defined in it --- System/Console/Haskeline/Backend/Posix.hsc |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/System/Console/Haskeline/Backend/Posix.hsc b/System/Console/Haskeline/Backend/Posix.hsc index db9c66e..74bba7a 100644 --- a/System/Console/Haskeline/Backend/Posix.hsc +++ b/System/Console/Haskeline/Backend/Posix.hsc @@ -48,7 +48,7 @@ import GHC.IOBase(haFD,FD) import GHC.Handle (withHandle_) #endif -#ifdef USE_TERMIOS_H +#if defined(USE_TERMIOS_H) || defined(__ANDROID__) #include termios.h #endif #include sys/ioctl.h @@ -64,7 +64,6 @@ ehOut = eH . hOut --- -- Window size - foreign import ccall ioctl :: FD - CULong - Ptr a - IO CInt posixLayouts :: Handles - [IO (Maybe Layout)] -- 1.7.10.4 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [PATCH] Re: HEADS UP (was Re: [commit: ghc] master: Tidy up cross-compiling (109a1e5))
On Thu, 24 Jan 2013 15:06:58 + Simon Marlow marlo...@gmail.com wrote: On 23/01/13 23:44, Sergei Trofimovich wrote: mkGmpDerivedConstants is built for target and ran on host [attached patches for it] Thanks, I pushed your patches today. Cheers, Simon I see a ghc patch in tree, but not integer-gmp one: https://github.com/ghc/packages-integer-gmp/commits/master Thanks! -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
[PATCH] add better support for Raspberry Pi board
This patch adds support for Raspberry Pi board. The board is based on Broadcom BCM2835, which includes ARM1176JZF-S CPU core. The core is classical ARM11 so implementing ARMv6 ISA, but also provides VFPv2 FPU unit. As this looks like fairly popular hardware, in this patch we assume detected ARMv6 hardware to support VFPv2. Also as Raspberry Pi is very commonly used with hard-float ABI Linux distribution, the patch relaxes a condition of hard-float support for ARMv7 only to any general ARM core. --- aclocal.m4 |2 +- compiler/main/DriverPipeline.hs |9 ++--- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/aclocal.m4 b/aclocal.m4 index edbe389..b23568f 100644 --- a/aclocal.m4 +++ b/aclocal.m4 @@ -369,7 +369,7 @@ AC_DEFUN([GET_ARM_ISA], [AC_DEFINE(arm_HOST_ARCH_PRE_ARMv7, 1, [ARM pre v7]) changequote(, )dnl ARM_ISA=ARMv6 - ARM_ISA_EXT=[] + ARM_ISA_EXT=[VFPv2] changequote([, ])dnl ], [changequote(, )dnl diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs index c24bb51..81d0bc0 100644 --- a/compiler/main/DriverPipeline.hs +++ b/compiler/main/DriverPipeline.hs @@ -1454,14 +1454,17 @@ runPhase LlvmLlc input_fn dflags else if (elem VFPv3D16 ext) then [-mattr=+v7,+vfp3,+d16] else [] + ArchARM ARMv6 ext _ - if (elem VFPv2 ext) + then [-mattr=+v6,+vfp2] + else [-mattr=+v6] _ - [] -- On Ubuntu/Debian with ARM hard float ABI, LLVM's llc still -- compiles into soft-float ABI. We need to explicitly set abi -- to hard abiOpts = case platformArch (targetPlatform dflags) of -ArchARM ARMv7 _ HARD - [-float-abi=hard] -ArchARM ARMv7 _ _- [] -_- [] +ArchARM _ _ HARD - [-float-abi=hard] +ArchARM _ _ _- [] +_- [] sseOpts | isSse4_2Enabled dflags = [-mattr=+sse42] | isSse2Enabled dflags = [-mattr=+sse2] -- 1.7.3.2 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [PATCH] fix runtests to set LD_LIBRARY_PATH environment variable
On 01/25/13 09:40 PM, Simon Marlow wrote: On 25/01/13 19:12, Karel Gardas wrote: Hi Simon, it's simple, every lib is rpath-ed except the libffi. See: Then that sounds like a bug, no? IMHO it's more an expected behavior than a bug, but as Ian implemented it anyway, let's leave him a last word about it. From my point of view it looks like libffi is provided by any linux distro when you install GHC. (e.g. on ubuntu/debian you install ghc and libffi/libffi-dev is installed too). So this means on linux libffi is in /usr/lib and so available w/o any issue, it means the issue will not hit you on Linux. The problem I see is on Solaris. There is no system libffi and so ghc brings its own. The decision that libffi is linked only to rts lib seems to be also good as you don't need to decide while linking application if libffi is used or not. Simply link rts and be done with it. Another decision that libffi is linked into rts without rpath is also good IMHO as it allows you to move rts library around -- for example for installation. So well, that's at least my understanding of this and that's also the reason why I consider this to be more of expected behavior than of a bug... Anyway, thanks a lot for your very careful eyes following what's going into GHC and what not! Karel I'm not up to speed on this rpath stuff, maybe Ian knows what's going on. I'd rather not hide the bug by committing a workaround to the testsuite. Cheers, Simon End of readFile001 compilation with -v looks: *** Linker: /usr/sfw/bin/gcc -DTABLES_NEXT_TO_CODE -o readFile001 readFile001.o -L/export/home/karel/vcs/ghc-src/ghc-head/libraries/base/dist-install/build -Wl,-rpath -Wl,/export/home/karel/vcs/ghc-src/ghc-head/libraries/base/dist-install/build -L/export/home/karel/vcs/ghc-src/ghc-head/libraries/integer-gmp/dist-install/build -Wl,-rpath -Wl,/export/home/karel/vcs/ghc-src/ghc-head/libraries/integer-gmp/dist-install/build -L/export/home/karel/vcs/ghc-src/ghc-head/libraries/ghc-prim/dist-install/build -Wl,-rpath -Wl,/export/home/karel/vcs/ghc-src/ghc-head/libraries/ghc-prim/dist-install/build -L/export/home/karel/vcs/ghc-src/ghc-head/rts/dist/build -Wl,-rpath -Wl,/export/home/karel/vcs/ghc-src/ghc-head/rts/dist/build /tmp/ghc28147_0/ghc28147_0.o -lHSbase-4.7.0.0-ghc7.7.20130125 -lHSinteger-gmp-0.5.1.0-ghc7.7.20130125 -lgmp -lHSghc-prim-0.3.1.0-ghc7.7.20130125 -lHSrts-ghc7.7.20130125 -lm -lrt -ldl -u ghczmprim_GHCziTypes_Izh_static_info -u ghczmprim_GHCziTypes_Czh_static_info -u ghczmprim_GHCziTypes_Fzh_static_info -u ghczmprim_GHCziTypes_Dzh_static_info -u base_GHCziPtr_Ptr_static_info -u ghczmprim_GHCziTypes_Wzh_static_info -u base_GHCziInt_I8zh_static_info -u base_GHCziInt_I16zh_static_info -u base_GHCziInt_I32zh_static_info -u base_GHCziInt_I64zh_static_info -u base_GHCziWord_W8zh_static_info -u base_GHCziWord_W16zh_static_info -u base_GHCziWord_W32zh_static_info -u base_GHCziWord_W64zh_static_info -u base_GHCziStable_StablePtr_static_info -u ghczmprim_GHCziTypes_Izh_con_info -u ghczmprim_GHCziTypes_Czh_con_info -u ghczmprim_GHCziTypes_Fzh_con_info -u ghczmprim_GHCziTypes_Dzh_con_info -u base_GHCziPtr_Ptr_con_info -u base_GHCziPtr_FunPtr_con_info -u base_GHCziStable_StablePtr_con_info -u ghczmprim_GHCziTypes_False_closure -u ghczmprim_GHCziTypes_True_closure -u base_GHCziPack_unpackCString_closure -u base_GHCziIOziException_stackOverflow_closure -u base_GHCziIOziException_heapOverflow_closure -u base_ControlziExceptionziBase_nonTermination_closure -u base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -u base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -u base_ControlziExceptionziBase_nestedAtomically_closure -u base_GHCziWeak_runFinalizzerBatch_closure -u base_GHCziTopHandler_flushStdHandles_closure -u base_GHCziTopHandler_runIO_closure -u base_GHCziTopHandler_runNonIO_closure -u base_GHCziConcziIO_ensureIOManagerIsRunning_closure -u base_GHCziConcziSync_runSparks_closure -u base_GHCziConcziSignal_runHandlers_closure link: done *** Deleting temp files: Deleting: /tmp/ghc28147_0/ghc28147_0.o /tmp/ghc28147_0/ghc28147_0.c *** Deleting temp dirs: Deleting: /tmp/ghc28147_0 there is no libffi linked there as it's linked in RTS lib already. it's probably not rpath-ed there (for obvious reason) so ldd's output on the test looks: $ ldd readFile001 libHSbase-4.7.0.0-ghc7.7.20130125.so = /export/home/karel/vcs/ghc-src/ghc-head/libraries/base/dist-install/build/libHSbase-4.7.0.0-ghc7.7.20130125.so libHSinteger-gmp-0.5.1.0-ghc7.7.20130125.so = /export/home/karel/vcs/ghc-src/ghc-head/libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.5.1.0-ghc7.7.20130125.so libgmp.so.3 = /usr/lib/libgmp.so.3 libHSghc-prim-0.3.1.0-ghc7.7.20130125.so = /export/home/karel/vcs/ghc-src/ghc-head/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0-ghc7.7.20130125.so libHSrts-ghc7.7.20130125.so = /export/home/karel/vcs/ghc-src/ghc-head/rts/dist/build/libHSrts-ghc7.7.20130125.so libm.so.2 =
Re: [PATCH] add better support for Raspberry Pi board
BTW: I've forgot to mention: hard versus soft float abis are well detected by configure itself. So this is not the problem in my patch. The only issue is in testing/guessing for FPU/NEON. Good way may be to grep /proc/cpuinfo but this is only applicable while doing native compile on ARM-Linux platform. Is that what majority of GHC users will do? I don't think so as I think the way for majority will be cross-compilation but perhaps we can at least try it for those doing native compiles? What do you think about it? Thanks! Karel On 01/25/13 09:59 PM, Karel Gardas wrote: On 01/25/13 09:38 PM, Simon Marlow wrote: This would improve things for RPi, but we shouldn't be guessing here. gcc has predefines for the appropriate features: #define __ARM_PCS_VFP 1 indicates hard-float ABI, and #define __VFP_FP__ 1 indicates VFP presences (2 or 3? I don't know) The problem is that IIRC those defines are presented when you use appropriate GCC's command-line option. It does not tell anything about the target hardware itself. So that's why I'm just guessing in the patch. But honestly speaking do you think there is any other GHC user who would use GHC on ARMv6 and the hardware will be different than RPi? I think a chance for this is very low since otherwise everybody is using ARMv7 these days... Anyway, if you don't like guessing, what about to add few configure options which will drive the generation of ARM related bits into settings file and keeping some good defaults like we use now? i.e. ARMv7+VFPv3+NEON or ARMv6+VFPv2 or ARMv5 alone? Thanks! Karel Cheers, Simon On 25/01/13 15:56, Karel Gardas wrote: This patch adds support for Raspberry Pi board. The board is based on Broadcom BCM2835, which includes ARM1176JZF-S CPU core. The core is classical ARM11 so implementing ARMv6 ISA, but also provides VFPv2 FPU unit. As this looks like fairly popular hardware, in this patch we assume detected ARMv6 hardware to support VFPv2. Also as Raspberry Pi is very commonly used with hard-float ABI Linux distribution, the patch relaxes a condition of hard-float support for ARMv7 only to any general ARM core. --- aclocal.m4 | 2 +- compiler/main/DriverPipeline.hs | 9 ++--- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/aclocal.m4 b/aclocal.m4 index edbe389..b23568f 100644 --- a/aclocal.m4 +++ b/aclocal.m4 @@ -369,7 +369,7 @@ AC_DEFUN([GET_ARM_ISA], [AC_DEFINE(arm_HOST_ARCH_PRE_ARMv7, 1, [ARM pre v7]) changequote(, )dnl ARM_ISA=ARMv6 - ARM_ISA_EXT=[] + ARM_ISA_EXT=[VFPv2] changequote([, ])dnl ], [changequote(, )dnl diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs index c24bb51..81d0bc0 100644 --- a/compiler/main/DriverPipeline.hs +++ b/compiler/main/DriverPipeline.hs @@ -1454,14 +1454,17 @@ runPhase LlvmLlc input_fn dflags else if (elem VFPv3D16 ext) then [-mattr=+v7,+vfp3,+d16] else [] + ArchARM ARMv6 ext _ - if (elem VFPv2 ext) + then [-mattr=+v6,+vfp2] + else [-mattr=+v6] _ - [] -- On Ubuntu/Debian with ARM hard float ABI, LLVM's llc still -- compiles into soft-float ABI. We need to explicitly set abi -- to hard abiOpts = case platformArch (targetPlatform dflags) of - ArchARM ARMv7 _ HARD - [-float-abi=hard] - ArchARM ARMv7 _ _ - [] - _ - [] + ArchARM _ _ HARD - [-float-abi=hard] + ArchARM _ _ _ - [] + _ - [] sseOpts | isSse4_2Enabled dflags = [-mattr=+sse42] | isSse2Enabled dflags = [-mattr=+sse2] ___ 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
