I believe I've just pushed a fix for this, let me know if you still have
problems.
Cheers,
Simon
On 10/10/2014 13:47, Carter Schonwald wrote:
likewise, 32bit OS X seems to be broken on HEAD too
http://lpaste.net/112412 is the relevant bit
make[5]: Nothing to be done for `all'.
Sorry about this folks, I'm going to guess at the fix and validate it.
Cheers,
Simon
On 10/10/2014 10:51, Karel Gardas wrote:
On 10/10/14 09:19 AM, Páli Gábor János wrote:
Hello there,
Looks one of the recent commits broke the x86 builds on multiple
platforms [1][2][3]. The common error
On 10/10/2014 9:40 PM, Páli Gábor János wrote:
2014-10-10 13:30 GMT+02:00 cg chengan...@gmail.com:
How can I configure to build x86_64?
When I build GHC (with msys2), it always builds i386 and I haven't spotted
the option in ./configure to choose a x86_64 release.
This is implicitly
On 2014-10-10 at 09:19:31 +0200, Páli Gábor János wrote:
Looks one of the recent commits broke the x86 builds on multiple
platforms [1][2][3]. The common error message basically is as
follows:
rts/Linker.c: In function 'mkOc':
rts/Linker.c:2372:6:
error: 'ObjectCode' has no member
On 10/10/14 09:19 AM, Páli Gábor János wrote:
Hello there,
Looks one of the recent commits broke the x86 builds on multiple
platforms [1][2][3]. The common error message basically is as
follows:
rts/Linker.c: In function 'mkOc':
rts/Linker.c:2372:6:
error: 'ObjectCode' has no member
2014-10-10 13:30 GMT+02:00 cg chengan...@gmail.com:
How can I configure to build x86_64?
When I build GHC (with msys2), it always builds i386 and I haven't spotted
the option in ./configure to choose a x86_64 release.
This is implicitly determined by the toolchain you use. So, probably
you
likewise, 32bit OS X seems to be broken on HEAD too
http://lpaste.net/112412 is the relevant bit
make[5]: Nothing to be done for `all'.depbase=`echo src/x86/win32.lo |
sed 's|[^/]*$|.deps/|;s|\.lo$||'`;\
/bin/sh ./libtool--mode=compile gcc-4.9 -DHAVE_CONFIG_H -I. -I..
-I.
Indeed, but this looks like completely unrelated to the issue originally
reported. Kind of libffi misdetection of target platform? i.e. why it
compiles win32 related file on macosx?
Just trying to categorize not to decrease importance of this issue!
Karel
On 10/10/14 10:47 PM, Carter
could be! i'm not equipped to do the right debuggin atm though (i may try
to help out if can get some guidance though )
On Fri, Oct 10, 2014 at 4:55 PM, Karel Gardas karel.gar...@centrum.cz
wrote:
Indeed, but this looks like completely unrelated to the issue originally
reported. Kind of
