At HVR’s suggestion, I tried passing —with-nm=…/nm-classic to configure and that indeed fixes the problem, confirming that this is #11744. A fix is simple in this case, check whether `xcode-select -p`/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm-classic or `xcode-select -p`/usr/bin/nm-classic exists. If yes, use that instead of ’nm’; otherwise, use ’nm’ as usual. (You need to check for both, because the former is what comes with Xcode and the latter is what comes with the standalone command line tool package.) Thanks, Manuel

Am 26 Mar 2016 um 20:53 schrieb Erik de Castro Lopo :

Manuel M T Chakravarty wrote:

...

I just noticed that GHC 7.10.3 (latest release version) fails to build with version 7.3 of Xcode (which just came out of beta). Maybe this is due to

https://ghc.haskell.org/trac/ghc/ticket/11744

Yes, pretty sure that is the problem. I believe Carter (and maybe Luite) are working on it.

Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Sorry I see that Manuel mentioned the problem with 8.0.1 rc2 alreadyin his first email about this On Wed, Apr 13, 2016 at 2:43 PM George Colpitts wrote:

It turns out, not surprisingly, that this also breaks ghc 8, but in a totally different way, see https://ghc.haskell.org/trac/ghc/ticket/11823#comment:13

On Sat, Mar 26, 2016 at 6:35 AM Manuel M T Chakravarty < chak@justtesting.org> wrote:

...

I just noticed that GHC 7.10.3 (latest release version) fails to build with version 7.3 of Xcode (which just came out of beta). Maybe this is due to

https://ghc.haskell.org/trac/ghc/ticket/11744

The problem manifests in the form of a SEGV when dll-split is invoked for the first time — specifically lldb has the following to say,

Process 17348 launched: '../lib/bin/dll-split' (x86_64) Process 17348 stopped * thread #1: tid = 0x4a821e, 0x0000000100e26357 libHSrts-ghc7.10.3.dylib`stg_returnToStackTop + 7, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1e) frame #0: 0x0000000100e26357 libHSrts-ghc7.10.3.dylib`stg_returnToStackTop + 7 libHSrts-ghc7.10.3.dylib`stg_returnToStackTop: -> 0x100e26357 <+7>: movq 0x1e(%rax), %rbx 0x100e2635b <+11>: movq 0x10(%rbx), %rbp 0x100e2635f <+15>: leaq 0x126(%rbx), %r15 0x100e26366 <+22>: movq $0x0, 0x904(%r13)

Interestingly, the GHC 8.0.1-rc2 build does not exhibit that same failure. It does, however, fail to build due to an undefined symbol:

Undefined symbols for architecture x86_64: "_stg_sel_18_upd_info", referenced from: _sc9J_info in Monad.dyn_o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) `gcc' failed in phase `Linker'. (Exit code: 1) make[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1 make: *** [all] Error 2

(This may be unrelated to Xcode 7.3 and a known problem on OS X with that RC. I didn’t follow the 8.0.1-rc2 tickets in detail.)

As I assume that there will be no further 7.10 release, I am posting this here just to save others the time to track the problem down.

Manuel

PS: I wish I had the time to check GHC builds with Xcode beta releases, but alas, I usually don’t. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs