- ghc-devs - Haskell.org

`binary` serializing datatypes deriving Generic wrong on arm (32bit) with GHC HEAD
by Moritz Angermann 28 Nov '17

28 Nov '17

Hi! while trying to make sure cross compilation with Template Haskell works properly with 8.4, I ran into the following situation: When serializing data types, e.g. `Name OccName NameFlavour` in the transmission of Template Haskell Splice results from a 32bit arm device to the x86_64 host ghc. We expect to see: ``` .- 0 (first constructor) .- 1 .- 4 (fifth constructor) .- 4 .- 3 v v v v v \NUL \NUL\NUL\NUL\NUL\NUL\NUL\NUL\SOHf \EOT \NUL \NUL\NUL\NUL\NUL\NUL\NUL\NUL\EOTmain \NUL\NUL\NUL\NUL\NUL\NUL\NUL\ETXTmp '--' '----------------------------------' '---------------------------------' NameSpace PkgName ModName '-------------------------------' '--------------------------------------------------------------------------------' OccName NameG NameSpace PkgName ModName :: NameFlavour '-----------------------------------------------------------------------------------------------------------------------' Name OccName NameFlavour :: Name ``` However, the `NameSpace` on the 32bit arm ends up being 8 bytes. Even though the full `Namespace` data type can be fully serialized in a single byte. The `binary` package tries to compute the size it needs for a generic data type, using the following logic (from binary/src/Data/Binary/Generic.hs): ``` class SumSize f where sumSize :: Tagged f Word64 newtype Tagged (s :: * -> *) b = Tagged {unTagged :: b} instance (SumSize a, SumSize b) => SumSize (a :+: b) where sumSize = Tagged $ unTagged (sumSize :: Tagged a Word64) + unTagged (sumSize :: Tagged b Word64) instance SumSize (C1 c a) where sumSize = Tagged 1 ``` Thus for a simple sum type `data X = A | B` we should get a `sumSize` of 2. The arm32 device however ends up getting 2^33, because `sumSize :: Tagged a Word64` and `sumSize :: Tagged b Word64` each end up being 2^32. With some help from the nice folks in #ghc, I was able to conjure up the following condensed test case: ``` {-# LANGUAGE DeriveGeneric, KindSignatures, PolyKinds, CPP, ScopedTypeVariables, TypeOperators, TypeSynonymInstances, FlexibleInstances #-} {-# OPTIONS_GHC -O2 #-} import GHC.Generics import Data.Word import Debug.Trace data X = A | B deriving (Show, Generic) main :: IO () main = print (sumSize :: Tagged (Rep X)) -- like traceShowId, but allows us to prepend a message. t :: Show a => String -> a -> a #if TRACE t msg x = traceShow (msg ++ show x) x #else t _ = id #endif class SumSize f where sumSize :: Tagged f newtype Tagged (s :: * -> *) = Tagged {unTagged :: WORD} deriving Show instance (SumSize a, SumSize b) => SumSize (a :+: b) where sumSize = t "SumSize (a :+: b): " $ Tagged $ unTagged (t "a :+: b => sumSize :: Tagged a: " $ sumSize :: Tagged a) + unTagged (t "a :+: b => sumSize :: Tagged b: " $ sumSize :: Tagged b) instance SumSize (C1 c a) where sumSize = t "SumSize (C1 c a): " $ Tagged 1 instance SumSize a => SumSize (M1 D c a) where sumSize = t "SumSize (M1 D c a): " $ Tagged . unTagged $ (sumSize :: Tagged a) ``` compiling this with `-DWORD=Word32 -DTRACE=1` yields the correct result (=2), with `-DWORD=Word64 -DTRACE=0` as well. With `-DWORD=Word64 -DTRACE=2` the wrong result (=2^33) Optimization flags seem not to play any role when everything is in a single module (as the test case). As such I have attached the `-ddump-simple -dsuppress-all` files for the Word64 and Word32 with TRACE=1, as well as the diff between the Word32 and Word64 dump. The output with WORD=Word32, TRACE=1 is: ``` "SumSize (C1 c a): Tagged {unTagged = 1}" "a :+: b => sumSize :: Tagged a: Tagged {unTagged = 4294967296}" "a :+: b => sumSize :: Tagged b: Tagged {unTagged = 4294967296}" "SumSize (a :+: b): Tagged {unTagged = 8589934592}" "SumSize (M1 D c a): Tagged {unTagged = 8589934592}" Tagged {unTagged = 8589934592} ``` with WORD=Word64, TRACE=1 is: ``` "SumSize (C1 c a): Tagged {unTagged = 1}" "a :+: b => sumSize :: Tagged a: Tagged {unTagged = 1}" "a :+: b => sumSize :: Tagged b: Tagged {unTagged = 1}" "SumSize (a :+: b): Tagged {unTagged = 2}" "SumSize (M1 D c a): Tagged {unTagged = 2}" Tagged {unTagged = 2} ``` Any help with this would be greatly appreciated! Cheers, Moritz PS: I'm not absolutely sure, but this might also be related to https://ghc.haskell.org/trac/ghc/ticket/13513

1 1

True multi stage Haskell
by Tim Sheard 27 Nov '17

27 Nov '17

After many years of hoping someone else would do this, I would like to make GHC into a true multi-stage programming language. Here is how I thought I might approach this. 1) Use the GHC as a library module. 2) Use the LLVM backend. I have no experience with either of these tools. Lets start simple, How would I write functions like compile :: String -> IO PtrToLLVMCode -- where the string is a small Haskell program. llvmCompile :: PtrToLLVMCode -> IO PtrToMachineCode jumpTo:: PtrToMachineCode -> IO ans -- where ans is the "type" of the string. Any thoughts on how to get started? What papers to read, examples to look at? I'd love to move to some more disciplined input type, a sort of (mono) typed program representation (with similar complexity) to Template Haskell Exp type. where (Exp t) is a data structure representing a Haskell program of type t. All offers of advice accepted. I'm trying to get started soon, and good advice about what to avoid is especially welcome. If any one wanted to help with this, that would be great. Tim Sheard

6 5

Can strict ST break referential transparency?
by Yuras Shumovich 23 Nov '17

23 Nov '17

Hello, I was evaluating a possibility that linear types can break referential transparency [1], exactly like lazy ST [2]. But on the way I realized that even strict ST may suffer from the same issue. If ST computation is interrupted by e.g. async exception, runtime will "freeze" it at the point where it was interrupted [3]. So the question: is the "freezed" computation just a normal thunk? Note that the runtime doesn't guarantee that a thunk will be evaluated only once [4]. If the "freezed" thunk captures e.g. STRef, and will be evaluated twice, its effect could become observable from outside, just like in case of lazy ST. I tried to check the theory by stress testing RTS. Unfortunately I immediately discovered a runtime crash [5], which is probably not related to my question. Hope someone will be able to clarify things for me. Thanks, Yuras. [1] https://github.com/ghc-proposals/ghc-proposals/pull/91#issuecomment -345553071 [2] https://ghc.haskell.org/trac/ghc/ticket/14497 [3] See section 8 there: https://www.microsoft.com/en-us/research/wp-co ntent/uploads/2016/07/asynch-exns.pdf [4] https://www.microsoft.com/en-us/research/wp-content/uploads/2005/09 /2005-haskell.pdf [5] https://ghc.haskell.org/trac/ghc/ticket/14497

3 4

Re: [GHC] #14490: TTG Snags
by Alan & Kim Zimmerman 23 Nov '17

23 Nov '17

Yes, but it is not feasible before GHC 8.6, due to needing GHC >= 8.2 for bootstrapping. On 22 November 2017 at 15:26, GHC <ghc-devs(a)haskell.org> wrote: > #14490: TTG Snags > -------------------------------------+---------------------- > --------------- > Reporter: alanz | Owner: (none) > Type: bug | Status: new > Priority: normal | Milestone: > Component: Compiler | Version: 8.3 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: #14482 | Differential Rev(s): > Wiki Page: | > ImplementingTreesThatGrow | > -------------------------------------+---------------------- > --------------- > > Comment (by Shayan-Najd): > > > So making a Data instance per concrete version may be the best way to > go. Plan B. > > Regardless of the GHC version we use, the question is whether Plan B > really fixes the build-time problem. Can we test it? > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14490#comment:31> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

2 1

Unstuck old messages
by John Wiegley 23 Nov '17

23 Nov '17

Hello everyone, I was doing some maintenance on the mailman server that hosts this list, and several messages that were stuck in the queue for what appears to be a rather long time have been released. The queue is now empty, so if these messages are no longer relevant, please ignore them. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2

1 0

Re: Can strict ST break referential transparency?
by Yuras Shumovich 23 Nov '17

23 Nov '17

22-11-2017, Срд а 15:37 -0500, David Feuer напісаў: > If there is indeed a problem, I suspect the right way to fix it is to > make sure that no partially evaluated thunk is ever resumed twice. > Inter-thread exceptions are presumably rare enough that we don't have > to worry *too* much about their cost. Sounds reasonable. But probably it already works that way? Though it doesn't seem to be covered in the papers, and looks like nobody knows an answer to my question. It makes me worry a bit. On the other hand, right now resuming frozen thunk usually crashes/hangs as discovered in #14497. Nobody noticed that so far in the wild, so probably the subject is just a dark corner case, not worse the efforts. > > > David FeuerWell-Typed, LLP > -------- Original message --------From: Yuras Shumovich <shumovichy@g > mail.com> Date: 11/21/17 12:43 PM (GMT-05:00) To: ghc-devs <ghc-dev > s(a)haskell.org> Subject: Can strict ST break referential > transparency? > > Hello, > > I was evaluating a possibility that linear types can break > referential > transparency [1], exactly like lazy ST [2]. > > But on the way I realized that even strict ST may suffer from the > same > issue. If ST computation is interrupted by e.g. async exception, > runtime will "freeze" it at the point where it was interrupted [3]. > > So the question: is the "freezed" computation just a normal thunk? > Note > that the runtime doesn't guarantee that a thunk will be evaluated > only > once [4]. If the "freezed" thunk captures e.g. STRef, and will be > evaluated twice, its effect could become observable from outside, > just > like in case of lazy ST. > > I tried to check the theory by stress testing RTS. Unfortunately I > immediately discovered a runtime crash [5], which is probably not > related to my question. > > Hope someone will be able to clarify things for me. > > Thanks, > Yuras. > > [1] https://github.com/ghc-proposals/ghc-proposals/pull/91#issuecomme > nt > -345553071 > [2] https://ghc.haskell.org/trac/ghc/ticket/14497 > [3] See section 8 there: https://www.microsoft.com/en-us/research/wp- > co > ntent/uploads/2016/07/asynch-exns.pdf > [4] https://www.microsoft.com/en-us/research/wp-content/uploads/2005/ > 09 > /2005-haskell.pdf > [5] https://ghc.haskell.org/trac/ghc/ticket/14497 > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

Re: Can strict ST break referential transparency?
by David Feuer 22 Nov '17

22 Nov '17

If there is indeed a problem, I suspect the right way to fix it is to make sure that no partially evaluated thunk is ever resumed twice. Inter-thread exceptions are presumably rare enough that we don't have to worry *too* much about their cost. David FeuerWell-Typed, LLP -------- Original message --------From: Yuras Shumovich <shumovichy(a)gmail.com> Date: 11/21/17 12:43 PM (GMT-05:00) To: ghc-devs <ghc-devs(a)haskell.org> Subject: Can strict ST break referential transparency? Hello, I was evaluating a possibility that linear types can break referential transparency [1], exactly like lazy ST [2]. But on the way I realized that even strict ST may suffer from the same issue. If ST computation is interrupted by e.g. async exception, runtime will "freeze" it at the point where it was interrupted [3]. So the question: is the "freezed" computation just a normal thunk? Note that the runtime doesn't guarantee that a thunk will be evaluated only once [4]. If the "freezed" thunk captures e.g. STRef, and will be evaluated twice, its effect could become observable from outside, just like in case of lazy ST. I tried to check the theory by stress testing RTS. Unfortunately I immediately discovered a runtime crash [5], which is probably not related to my question. Hope someone will be able to clarify things for me. Thanks, Yuras. [1] https://github.com/ghc-proposals/ghc-proposals/pull/91#issuecomment -345553071 [2] https://ghc.haskell.org/trac/ghc/ticket/14497 [3] See section 8 there: https://www.microsoft.com/en-us/research/wp-co ntent/uploads/2016/07/asynch-exns.pdf [4] https://www.microsoft.com/en-us/research/wp-content/uploads/2005/09 /2005-haskell.pdf [5] https://ghc.haskell.org/trac/ghc/ticket/14497 _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

[ANNOUNCE] GHC 8.2.2 released
by Ben Gamari 21 Nov '17

21 Nov '17

=============================================== The Glasgow Haskell Compiler -- version 8.2.2 =============================================== The GHC Team is pleased to announce a new minor release of GHC. This release builds on the performance and stability improvements of 8.2.1, fixing a variety of correctness bugs, improving error messages, and making the compiler more portable. Notable bug-fixes include * A correctness issue resulting in segmentation faults in some FFI-users (#13707, #14346) * A correctness issue resulting in undefined behavior in some programs using STM (#14171) * A bug which may have manifested in segmentation faults in out-of-memory condition (#14329) * clearBit of Natural no longer bottoms (#13203) * A specialisation bug resulting in exponential blowup of compilation time in some specialisation-intensive programs (#14379) * ghc-pkg now works even in environments with misconfigured NFS mounts (#13945) * GHC again supports production of position-independent executables (#13702) * Better error messages around kind mismatches (#11198, #12373, #13530, #13610) A thorough list of the changes in the release can be found in the release notes, https://haskell.org/ghc/docs/8.2.2/html/users_guide/release-8-2-2.html How to get it ~~~~~~~~~~~~~ This release can be downloaded from https://www.haskell.org/ghc/download_ghc_8_2_2.html For older versions see https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Background ~~~~~~~~~~ Haskell is a standardized lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page https://www.haskell.org/ghc/ GHC developers' home page https://ghc.haskell.org/trac/ghc/ Haskell home page https://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: https://ghc.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site: https://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Many GHC developers hang out on #haskell on IRC: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: https://www.haskell.org/ghc/reportabug

1 1

Commit Notifications Flood
by Ara Adkins 21 Nov '17

21 Nov '17

Is anyone else getting an absolute flood of commit emails related to haddock? I remember this happening a little while back with the hadrian merge into the GHC tree. Best, _ara

3 4

Re: Linux failure
by David Feuer 20 Nov '17

20 Nov '17

Digging around online, I suspect that you may not have the GNU C++ compiler installed at all. Take this with a shaker of salt. David FeuerWell-Typed, LLP -------- Original message --------From: Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org> Date: 11/20/17 8:14 AM (GMT-05:00) To: ghc-devs(a)haskell.org Subject: Linux failure Hi devs I've got my Linux box upgraded to a recent version of Ubuntu, so I'm no longer stuck on gcc version. But I can't build either. Something strange with /lib/cpp fails sanity check. The log is below. Can anyone help? I'm a bit stalled. This call to "make" follows the same failure when I typed "sh validate -fast". But by carrying on from where it got stuck the log is way shorter. Thanks Simon simonpj@cam-05-unx:~/5builds/HEAD$ make ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for 'phase_1_builds'. ===--- building final phase make --no-print-directory -f ghc.mk phase=final all rts/ghc.mk:547: rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm: No such file or directory libraries/ghci/ghc.mk:4: libraries/ghci/dist-install/build/.depend-v-dyn.haskell: No such file or directory "rm" -f libffi/stamp.ffi.static.configure "rm" -f libffi/stamp.ffi.static.build "rm" -f libffi/stamp.ffi.static.install "rm" -f libffi/stamp.ffi.static-shared.configure "rm" -f libffi/stamp.ffi.static-shared.build "rm" -f libffi/stamp.ffi.static-shared.install "rm" -rf libffi/build cat libffi-tarballs/libffi*.tar.gz | /bin/gzip -d | { cd libffi && /bin/tar -xf - ; } mv libffi/libffi-* libffi/build cp "/home/simonpj/5builds/HEAD/config.guess" libffi/build/config.guess cp "/home/simonpj/5builds/HEAD/config.sub" libffi/build/config.sub chmod +x libffi/ln # We need to use -MMD rather than -MD, as otherwise we get paths # like c:/... in the dependency files on Windows, and the extra # colons break make mv libffi/build/Makefile.in libffi/build/Makefile.in.orig sed "s/-MD/-MMD/" < libffi/build/Makefile.in.orig > libffi/build/Makefile.in # We attempt to specify the installation directory below with --libdir, # but libffi installs into 'toolexeclibdir' instead, which may differ # on systems where gcc has multilib support. Force libffi to use libdir. # (https://sourceware.org/ml/libffi-discuss/2014/msg00016.html) mv libffi/build/Makefile.in libffi/build/Makefile.in.orig sed 's:@toolexeclibdir@:$(libdir):g' < libffi/build/Makefile.in.orig > libffi/build/Makefile.in # install-sh is used when /usr/bin/install is missing; ensure its # path in libffi's Makefile is correct. See GHC #11109. mv libffi/build/Makefile.in libffi/build/Makefile.in.orig sed 's|@INSTALL@|$(subst ../install-sh,/home/simonpj/5builds/HEAD/install-sh,@INSTALL@)|g' < libffi/build/Makefile.in.orig > libffi/build/Makefile.in cd libffi && \ cd build && \ CC=gcc \ CXX=gcc \ LD=ld.gold \ AR=ar \ NM=nm \ RANLIB=ranlib \ CFLAGS="-Wall -Werror -fno-stack-protector -w" \ LDFLAGS=" -w" \ "/bin/bash" ./configure \ --prefix=/home/simonpj/5builds/HEAD/libffi/build/inst \ --libdir=/home/simonpj/5builds/HEAD/libffi/build/inst/lib \ --disable-docs \ --enable-static=yes \ --enable-shared=yes \ --host=x86_64-unknown-linux checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu continue configure in default builddir "./x86_64-unknown-linux-gnu" ....exec /bin/sh .././configure "--srcdir=.." "--enable-builddir=x86_64-unknown-linux-gnu" "linux gnu" checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for gsed... sed checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for x86_64-unknown-linux-strip... no checking for strip... strip checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking for x86_64-unknown-linux-gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking whether we are using the GNU C++ compiler... no checking whether gcc accepts -g... no checking dependency style of gcc... gcc3 checking dependency style of gcc... gcc3 checking how to print strings... printf checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by gcc... ld.gold checking if the linker (ld.gold) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... nm checking the name lister (nm) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1635000 checking how to convert x86_64-pc-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop checking for ld.gold option to reload object files... -r checking for x86_64-unknown-linux-objdump... no checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for x86_64-unknown-linux-dlltool... no checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for x86_64-unknown-linux-ar... ar checking for archiver @FILE support... @ checking for x86_64-unknown-linux-strip... strip checking for x86_64-unknown-linux-ranlib... ranlib checking command to parse nm output from gcc object... ok checking for sysroot... no checking for a working dd... /bin/dd checking how to truncate binary pipes... /bin/dd bs=4096 count=1 checking for x86_64-unknown-linux-mt... no checking for mt... mt checking if mt is a manifest tool... no checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (ld.gold -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking how to run the C++ preprocessor... /lib/cpp configure: error: in `/home/simonpj/5builds/HEAD/libffi/build/x86_64-unknown-linux-gnu': configure: error: C++ preprocessor "/lib/cpp" fails sanity check See `config.log' for more details libffi/ghc.mk:47: recipe for target 'libffi/stamp.ffi.static-shared.configure' failed make[1]: *** [libffi/stamp.ffi.static-shared.configure] Error 1 Makefile:122: recipe for target 'all' failed make: *** [all] Error 2

1 0