Hello,
perhaps it might be possible to selectively disable dtrace on 10.5? I'm
kind of also affected by this patch as my patch to enable DTrace on
i386-solaris2 platform still awaits review[1] and with this patch
applied it just do nothing (well, user needs to enable USE_DTRACE...).
So more
Hello,
I've noticed that there was a GHC-HQ GHC git repo on GitHub.com here:
https://github.com/ghc-hq/ghc -- I'm curious is this going to be
updated/mirrored again when GHC HQ team is using git again? I'm asking
especially since I've not found any `git send' command which will allow
me to
Hello,
I'm trying to find out if current HEAD NCG supports some kind of
conditional instructions. On x86/amd64 this is cmov for example and on
PPC this might be fsel. So far it looks like NCG does not know anything
about those instructions and also generic support in NCG does not look
Hello,
yesterday night build of HEAD fails with:
libraries/base/Data/Maybe.hs:67:7:
Can't find interface-file declaration for data constructor GHC.Generics.Inl
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
In the
Hello,
this patch breaks build on Solaris. The error is caught by opensolaris
builder here:
http://darcs.haskell.org/ghcBuilder/builders/kgardas-opensolaris-x86-head/153.html
concretely the error shows like:
[...]
checking for __mingw_vfprintf... no
configure: creating ./config.status
for you?
Thanks,
Karel
On 03/11/11 02:42 PM, Ian Lynagh wrote:
Hi Karel,
On Thu, Mar 10, 2011 at 07:51:45PM +0100, Karel Gardas wrote:
this patch attempts to fix configure breakage on Solaris. I hope the
code still runs well on apple/xcode.
] hunk ./configure.ac 443
if test
On 03/11/11 04:25 PM, Ian Lynagh wrote:
On Fri, Mar 11, 2011 at 03:06:49PM +0100, Karel Gardas wrote:
no, this does not work. Anyway, the problem is caused or looks like
to be caused by using double test. This:
elif test $XCodeVersion1 -eq 3 -a $XCodeVersion2 -lt 2
for example works
Hello,
I've read
http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions/Git and it
contains following sentence:
(where account is your account on darcs.haskell.org; omit this step
if you don't have one, you can still submit patches via the mailing list
or send a pull request to get
Edward,
I'm not sure if I'm not mistaken, but if I invoke:
git clone http://darcs.haskell.org/ghc.git
I still see those commits on top of the log (git log command):
commit 5305c38484cccf341e761e05614d414cd77dfec9
Merge: 2c618c2 ce2ea82
Author: unknown simo...@.europe.corp.microsoft.com
Date:
This patch fixes issue with version date processing on Solaris while using
Solaris' provided sed. I don't know sed enough to remove GNUism in version
date processing so I replaced sed usage in this task by few cut calls.
---
aclocal.m4 |6 +-
1 files changed, 5 insertions(+), 1
On 04/18/11 08:13 AM, Matthias Kilian wrote:
On Sun, Apr 17, 2011 at 11:44:33PM +0200, Karel Gardas wrote:
This patch fixes issue with version date processing on Solaris while using
Solaris' provided sed. I don't know sed enough to remove GNUism in version
date processing so I replaced sed
---
tests/ghc-regress/rts/all.T |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/tests/ghc-regress/rts/all.T b/tests/ghc-regress/rts/all.T
index 3adc725..a008e3b 100644
--- a/tests/ghc-regress/rts/all.T
+++ b/tests/ghc-regress/rts/all.T
@@ -77,6 +77,8 @@ test('T2615',
Hello,
I'm attempting to make ARM registerised build reality just for own fun
(and thanks to help and encouragement provided by David Terei) and for
this I'm writing platform specific StgRun/StgReturn functions as
required in rts/StgCRun.c. I'm not sure I've got right all the
information
On 05/18/11 12:09 PM, Simon Marlow wrote:
The real difficulty with the ghc sources is that fact that
over a dozen different trees, with independant commit histories
are needed to retrieve a working revision.
Right, this is something that would be fixed by using submodules or
subtree merging.
Hello,
it looks like GHC builder server which pushes tasks to builder clients
needs restart. I'm attempting to restart my builder client during the
last days and always got:
[2011-05-22 14:19:22] [kgardas-opensolaris-x86-head] Connecting...
builder-client: connect: timeout (Connection timed
It looks like where x86 assembly is using '@' character,
ARM assembly requires '%' character. This makes a problem in the patch
814edf44433801e37318ce79082ac6991dbc87dd 'Force re-linking if
the options have changed (#4451)' which makes linking assembly
file uncompilable on ARM. This patch fixes
Hello,
while building June's 1st GHC HEAD sources on arm-linux platform I'm hit
by this issue:
inplace/bin/ghc-stage2 -O0 -H32m -optc-O0-package-name
vector-0.7.0.1 -hide-all-packages -i -ilibraries/vector/.
-ilibraries/vector/dist-install/build
On 06/13/11 10:08 AM, Simon Peyton-Jones wrote:
Well, yes. If bytecode generation isn't available for ARM, then Template Haskell won't
work. And in turn annotations won't work. So any library using these
features won't work.
That's a pity. How hard would it be to add bytecode generation
It looks like where x86 assembly is using '@' character,
ARM assembly requires '%' character. This makes a problem in the patch
814edf44433801e37318ce79082ac6991dbc87dd 'Force re-linking if
the options have changed (#4451)' which makes linking assembly
file uncompilable on ARM. This patch fixes
Sorry, this is a wrong version of the patch. I'm going to resend correct
one.
Karel
On 06/13/11 12:29 PM, Karel Gardas wrote:
It looks like where x86 assembly is using '@' character,
ARM assembly requires '%' character. This makes a problem in the patch
It looks like where x86 assembly is using '@' character,
ARM assembly requires '%' character. This makes a problem in the patch
814edf44433801e37318ce79082ac6991dbc87dd 'Force re-linking if
the options have changed (#4451)' which makes linking assembly
file uncompilable on ARM. This patch fixes
Hello,
I've done some benchmarking of ARM/LLVM registerised build in comparison
with ARM unregisterised builds using either C code gen or LLVM code gen.
The raw data are here:
http://www.gardas.roznovan.cz/ghc-on-arm/comparison-unreg-viaC-llvm-to-reg-llvm.html
From the performance point of
Hello,
while working on ARM port, I've found bug in WSDeque.c which might
possibly also hurt other architectures -- depending on how weak is their
memory model (i.e. how much load/store reordering it permits).
I'm certainly not sure if it affects x86, but I'm not sure if PowerPC is
safe
Hello,
I've forked ghc/ghc repo on github.com to work on ARM port. Now I'd like
to check it out and compile it, but I'm not able to `sync-all get' since
git complains with `warning: remote HEAD refers to nonexistent ref,
unable to checkout.'
I've also tested:
perl ./sync-all -r
On 07/11/11 01:10 PM, Simon Marlow wrote:
On 11/07/2011 11:36, Karel Gardas wrote:
Have you tried running some heavy -N2 tests? e.g. try the benchmarks in
nofib/parallel.
If this is part of normal nofib's `make' then this runs already.
No, it's not part of a normal nofib run. You want
Hello Johan,
On 07/12/11 03:48 PM, Johan Tibell wrote:
On Tue, Jul 12, 2011 at 3:34 PM, Karel Gardaskarel.gar...@centrum.cz wrote:
Hello,
I've forked ghc/ghc repo on github.com to work on ARM port. Now I'd like to
check it out and compile it, but I'm not able to `sync-all get' since git
David,
thanks a lot, this indeed works! Thank you also for your another help
with parallel needed by nofib. This also works...
Karel
On 07/12/11 07:16 PM, David Peixotto wrote:
The get command for the sync-all script was recently fixed with this commit
Hello,
I'm still fighting with how to precisely get ghc source tree from
github.com. Now I see some issues with libraries/Cabal, concretely what
you get from github.com is different to what you get from
haskell.org/ghc.git.
From haskell.org:
$ ls -la libraries/Cabal/
total 30
drwxr-xr-x
Hi Ian,
On 07/12/11 10:23 PM, Ian Lynagh wrote:
Hi Karel,
On Tue, Jul 12, 2011 at 10:11:56PM +0200, Karel Gardas wrote:
I'm still fighting with how to precisely get ghc source tree from
github.com. Now I see some issues with libraries/Cabal, concretely
what you get from github.com
On 07/13/11 02:26 AM, Ian Lynagh wrote:
Hi Karel,
On Tue, Jul 12, 2011 at 11:20:40PM +0200, Karel Gardas wrote:
$ perl sync-all -r http://darcs.haskell.org/ghc.git/ get
Use:
perl sync-all -r http://darcs.haskell.org/ get
Great! That works! Thanks a lot!
Karel
, as well as a how to guide.
Simon
| -Original Message-
| From: cvs-ghc-boun...@haskell.org [mailto:cvs-ghc-boun...@haskell.org] On
Behalf Of
| Johan Tibell
| Sent: 12 July 2011 14:48
| To: Karel Gardas
| Cc: cvs-ghc
| Subject: Re: ghc github.com help...
|
| On Tue, Jul 12, 2011 at 3:34 PM
Hello,
has testsuite python verson requirements changed recently? When my
opensolaris buildbot got to the point of starting testsuite it fails with:
echo '#!/bin/sh' install-inplace/bin/timeout
echo 'exec python $0.py $@' install-inplace/bin/timeout
chmod +x install-inplace/bin/timeout
Chakravarty
| Sent: 10 August 2011 13:16
| To: GHC
| Cc: Stephen Blackheath [to LLVM-dev]
| Subject: ARM support for the LLVM backend
|
| I just pushed the work of Stephen Blackheath and Karel Gardas with, I
believe, advise
| from David that adds ARM support to the LLVM backend and RTS.
|
| The ARM
This patch fixes missing import on non x86/amd64/ppc platform.
Since wORD_SIZE is not #ifdefed and hence is compiled on all platforms,
then also Constants import should not be (i.e. Constants import imports
wORD_SIZE definition).
---
compiler/nativeGen/X86/Regs.hs |3 ---
1 files changed, 0
Hello Ben,
I've been hit by this issue on OpenSolaris too[1]. I'm afraid the issue
is not in HEAD, but rather in 7.2.1 since when I switched back to 7.0.1
as a bootstrap compiler on my builder machine the issue went away
immediately.
Cheers,
Karel
[1]:
On 10/ 4/11 02:53 PM, Erik de Castro Lopo wrote:
I'm working on some changes (suggested by David Terei) to the LLVM
backend that I hope will improve compile times when going via LLVM.
Something like that is more than welcome on slow hosts which are using
LLVM -- i.e. GHC/ARM combination comes
Hi Ben,
this is indeed great news! I've just resurrected my pandaboard and
started a build of your tree to see how is it working. I'll let you know
in about 24 hours I guess (if everything is working well, if not, then
sooner. FYI: build takes about 6 hours and testsuite run about 12 hours
On 10/12/11 03:05 PM, Ben Gamari wrote:
Also, if you want to support -fPIC and -dynamic then you may have to
implement the other kinds of relocations that those generate.
Sigh.
For the first step I would concentrate on usual static build. I've
attempted build with shared libs enabled, but
---
mk/config.mk.in |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mk/config.mk.in b/mk/config.mk.in
index 89cce18..aef0937 100644
--- a/mk/config.mk.in
+++ b/mk/config.mk.in
@@ -137,7 +137,7 @@ PlatformSupportsSharedLibs = $(if $(filter
$(TARGETPLATFORM),\
# the
On 10/12/11 07:27 AM, Ben Gamari wrote:
I have finished a first cut of a patch doing the above and it is
available at [4]. Be aware that this is entirely untested (hopefully
this will change tomorrow after some sleep). Does anyone see anything
missing or blatantly wrong? Given my limited
On 10/12/11 07:57 PM, Ben Gamari wrote:
the system is Ubuntu 11.04. Looking into /usr/include/elf.h reveals no
R_ARM_THM_MOVW_ABS_NC nor R_ARM_THM_MOVT_ABS relocations defined.
Oh my, it seems you are right. This is quite strange as these are
defined in the ELF for the ARM Architecture
On 10/12/11 07:57 PM, Ben Gamari wrote:
On Wed, 12 Oct 2011 19:23:54 +0200, Karel Gardaskarel.gar...@centrum.cz
wrote:
On 10/12/11 07:27 AM, Ben Gamari wrote:
I have finished a first cut of a patch doing the above and it is
available at [4]. Be aware that this is entirely untested (hopefully
On 10/12/11 08:44 PM, Ben Gamari wrote:
On Wed, 12 Oct 2011 20:35:12 +0200, Karel Gardaskarel.gar...@centrum.cz
wrote:
I'm also using this to make it compilable:
Yep, you are right. Merged.
FYI, relocation type 43 still unhandled:
Loading package ghc-prim ... linking ... ghc-stage2:
On 10/13/11 01:06 AM, Ben Gamari wrote:
On Thu, 13 Oct 2011 00:15:39 +0200, Karel Gardaskarel.gar...@centrum.cz
wrote:
On 10/12/11 08:44 PM, Ben Gamari wrote:
On Wed, 12 Oct 2011 20:35:12 +0200, Karel Gardaskarel.gar...@centrum.cz
wrote:
I'm also using this to make it compilable:
Yep,
On 10/13/11 05:52 AM, Ben Gamari wrote:
On Thu, 13 Oct 2011 00:15:39 +0200, Karel Gardaskarel.gar...@centrum.cz
wrote:
On 10/12/11 08:44 PM, Ben Gamari wrote:
On Wed, 12 Oct 2011 20:35:12 +0200, Karel Gardaskarel.gar...@centrum.cz
wrote:
I'm also using this to make it compilable:
Yep,
On 10/13/11 05:28 PM, Ben Gamari wrote:
Also to get to this stage I needed to apply attached patch. However I'm
not sure I got `A' definition right hence just commenting out #ifdefs
Thanks for pointing this out. A actually shouldn't appear at all in this
code, it's just the variable that
On 10/13/11 08:22 PM, Ben Gamari wrote:
On Thu, 13 Oct 2011 19:02:24 +0200, Karel Gardaskarel.gar...@centrum.cz
wrote:
On 10/13/11 05:28 PM, Ben Gamari wrote:
Also to get to this stage I needed to apply attached patch. However I'm
not sure I got `A' definition right hence just commenting out
Hi Ben,
-fvia-C means you are building unregisterised build. Perhaps, you might
try registerised build or even that was your intention? For this you
will need to apply my submitted patch or do this yourself...
FYI: I'm just testing GHC HEAD with LLVM HEAD, where GHC HEAD is:
commit
Hi Ben,
what's wrong is your build.mk file. I'm using:
GhcLibWays = v
SplitObjs = NO
HADDOCK_DOCS = NO
BUILD_DOCBOOK_HTML = NO
BUILD_DOCBOOK_PS = NO
BUILD_DOCBOOK_PDF = NO
here and it's working well. Last GHC/LLVM/HEADs testsuite results are:
OVERALL SUMMARY for test run
On 10/14/11 12:52 AM, Ben Gamari wrote:
On Thu, 13 Oct 2011 19:02:24 +0200, Karel Gardaskarel.gar...@centrum.cz
wrote:
OK! Quick testing reveals:
Loading package ghc-prim ... linking ... ghc-stage2:
On 10/14/11 03:25 PM, Ben Gamari wrote:
On Fri, 14 Oct 2011 07:09:12 +0200, Karel Gardaskarel.gar...@centrum.cz
wrote:
Hi Ben,
what's wrong is your build.mk file. I'm using:
GhcLibWays = v
SplitObjs = NO
HADDOCK_DOCS = NO
BUILD_DOCBOOK_HTML = NO
BUILD_DOCBOOK_PS = NO
On 10/15/11 01:56 AM, Ben Gamari wrote:
On Fri, 14 Oct 2011 07:09:12 +0200, Karel Gardaskarel.gar...@centrum.cz
wrote:
Hi Ben,
Hmm, looking at compiler/ghc.mk, it seems the checks for whether the
architecture supports registerised builds and NCG don't check for ARM. I
suspect this is my
On 10/16/11 05:48 PM, Ben Gamari wrote:
I've implemented the transition logic for the JUMP24
relocation. Hopefully it is correct. I'll take a closer look over it
today to check that it's correct, but the rough idea has been
uploaded in the name of release early-release often.
This code is not
On 10/16/11 08:41 PM, Ben Gamari wrote:
On Sun, 16 Oct 2011 20:03:24 +0200, Karel Gardaskarel.gar...@centrum.cz
wrote:
Also I'm quite out of idea what was your intention on line above so I'm
not able to fix this myself.
Doh, yes. You are right. Fixed. I also fixed a serious oversight in my
On 10/16/11 09:28 PM, Ben Gamari wrote:
On Sun, 16 Oct 2011 21:06:27 +0200, Karel Gardaskarel.gar...@centrum.cz
wrote:
On 10/16/11 08:41 PM, Ben Gamari wrote:
On Sun, 16 Oct 2011 20:03:24 +0200, Karel Gardaskarel.gar...@centrum.cz
wrote:
Also I'm quite out of idea what was your
On 10/16/11 10:26 PM, Ben Gamari wrote:
On Sun, 16 Oct 2011 22:10:16 +0200, Karel Gardaskarel.gar...@centrum.cz
wrote:
On 10/16/11 09:28 PM, Ben Gamari wrote:
(snip)
Does not seems so. You still attempt to invoke makeArmSymbolExtra with
just 3 args, while it's defined with 4 and I'm not
On 10/16/11 11:29 PM, Ben Gamari wrote:
On Sun, 16 Oct 2011 22:43:52 +0200, Karel Gardaskarel.gar...@centrum.cz
wrote:
Now I got:
Fixed all of these. The problem was a misplaced #endif.
I still get:
rts/Linker.c: In function ‘do_Elf_Rel_relocations’:
rts/Linker.c:4339:16:
warning:
Hi Ben,
first of all, thank you very much for your progress. No, I don't see
crash, but in fact infinite loop. As far as I understand the linker
message '..linking...done' is printed when all the relocations are
processed -- so it does not necessarily mean that all the relocations
are
This patch fixes generation of settings file on ARM platform
by configure script. This fixes build issue on ARM platform
where ghc-stage1 compiler is not able to read the target arch
value and due to this issue build fails with:
ghc-cabal: Failed to read target arch value ArchARM ARMv7 [VFPv3,
On 10/22/11 06:24 PM, Ben Gamari wrote:
On Sat, 22 Oct 2011 16:58:18 +0200, Karel Gardaskarel.gar...@centrum.cz
wrote:
Hi Ben,
first of all, thank you very much for your progress. No, I don't see
crash, but in fact infinite loop. As far as I understand the linker
message '..linking...done'
Hello,
first I've not followed GHC development for about 2 months now so I'm
sorry if this is well known information.
Now I'm compiling ghc-7.4.0.20111215 snapshot obtained from haskell.org
on my ARM/Linux system. This fails with:
inplace/bin/ghc-stage1 -H32m -O-package-name
On 01/ 6/12 10:27 PM, Nathan Howell wrote:
I hit this one (might be the same?) on 7.2.1 on Linux x86_64:
ASSERT(t-cap == cap);
It happens somewhat frequently under load on a 16 core box.
Thanks for the information, however mine is previous one:
527
528
On 01/ 9/12 11:40 AM, Simon Marlow wrote:
Thanks for the information, however mine is previous one:
527
528 ASSERT_FULL_CAPABILITY_INVARIANTS(cap,task);
529 ASSERT(t-cap == cap);
530
and also this is on single-core ARM. Interesting...
This could be a problem. I haven't seen any of these in
Hello,
if this is desired, then is it possible to do this in non-standard nofib
run as this would probably kill any benchmarking on not so fast platform
like ARM...
Thanks!
Karel
On 01/18/12 10:50 AM, Simon Peyton-Jones wrote:
Thank you for doing this David. We need good benchmarks, and
On 01/18/12 08:22 PM, David Terei wrote:
On 18 January 2012 03:13, Karel Gardaskarel.gar...@centrum.cz wrote:
Hello,
if this is desired, then is it possible to do this in non-standard nofib run
as this would probably kill any benchmarking on not so fast platform like
ARM...
I assume you
On 01/18/12 11:13 PM, Gabor Greif wrote:
b) Sub-architecture (ArchPPC e500)
elegant, but more work
For ARM we're using something similar (see Platform.hs) as its elegant
and whole GHC code would like to get rid of platform specific #ifdefs
and move platform specific decision into Haskell.
Hello Simon,
On 01/ 9/12 11:40 AM, Simon Marlow wrote:
On 06/01/2012 21:30, Karel Gardas wrote:
On 01/ 6/12 10:27 PM, Nathan Howell wrote:
I hit this one (might be the same?) on 7.2.1 on Linux x86_64:
ASSERT(t-cap == cap);
It happens somewhat frequently under load on a 16 core box.
Don't
Ben,
big congratulations! And thanks a lot for your hard work on this. This
is indeed really great!
I'm looking at your patch for #5824 and will have few questions in
another email. I hope once this is solved I'll rerun your GHC tree
thorough my testing board here...
Thanks!
Karel
On
On 01/30/12 12:07 PM, Simon Marlow wrote:
up to 7.4.1 RC2 this was solely HEAD issue, now with 7.4.1 RC2 it shows
also on 7.4. The bug shows as:
internal error: ASSERTION FAILED: file rts/Schedule.c, line 506
(GHC version 7.4.0.20120126 for arm_unknown_linux)
Please report this as a GHC bug:
On 02/13/12 02:38 AM, Ricardo Wurmus wrote:
Hi,
I'm trying to compile my Haskell project on x86_64 with GHC 7.4.1 and
the LLVM backend for ARM, but LLVM's llc either segfaults (version
3.0) or aborts (2011-07-12 revision with patch as described here[1]).
I've filed a bug in the LLVM
Hello,
it looks like I always get following compilation error ARM/linux
platform (actually GHC ARM builder board). I've thought it's just broken
LLVM installed from not yet released ubuntu packages, but I also got
very similar issue on another board with hand-compiled LLVM (i.e.
optimization
it.
Karel
On 03/18/12 07:39 PM, Karel Gardas wrote:
Hello,
it looks like I always get following compilation error ARM/linux
platform (actually GHC ARM builder board). I've thought it's just broken
LLVM installed from not yet released ubuntu packages, but I also got
very similar issue on another
.
Thanks for any idea how to find the culprit of the issue below and fix it.
Karel
On 03/18/12 07:39 PM, Karel Gardas wrote:
Hello,
it looks like I always get following compilation error ARM/linux
platform (actually GHC ARM builder board). I've thought it's just broken
LLVM installed from not yet
---
compiler/nativeGen/X86/Regs.hs |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/compiler/nativeGen/X86/Regs.hs b/compiler/nativeGen/X86/Regs.hs
index ac44993..052cf02 100644
--- a/compiler/nativeGen/X86/Regs.hs
+++ b/compiler/nativeGen/X86/Regs.hs
@@ -410,6 +410,8
On 07/ 8/12 10:15 PM, Erik de Castro Lopo wrote:
Karel Gardas wrote:
---
compiler/nativeGen/X86/Regs.hs |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/compiler/nativeGen/X86/Regs.hs b/compiler/nativeGen/X86/Regs.hs
I already submitted a bug report and patch
Hi Gabor,
thanks a lot for your effort on GHC cross-compilation. You are talking
about cross-compiling to ARM too. I would like to warn you here as GHC
HEAD build for ARM is broken since February due to LLVM backend
miscompiling stage2 -- at least that's my analysis of this so far. See
Hello,
I'm trying to get GHC HEAD compilation working on my freshly installed
Solaris 11/x86 box and I'm trying to solve following error now:
/opt/ghc-7.4.2/bin/ghc -static -H32m -O -package-conf
libraries/bootstrapping.conf -package-name ghc-7.7 -hide-all-packages
-i
This works, indeed! Thanks a lot for this fast help!
Karel
On 10/29/12 11:07 PM, Gabor Greif wrote:
IIRC, I had to manually remove a 'Parser.y' file to get things rolling.
Cheers,
Gabor
On 10/29/12, Karel Gardaskarel.gar...@centrum.cz wrote:
Hello,
I'm trying to get GHC HEAD
Note that PRIdPTR is considered as linux-ism so it's not available on platforms
like Solaris, although some other free Unix(-like) OSes apparently supports
it too.
---
includes/mkDerivedConstants.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git
/12 06:59 PM, Karel Gardas wrote:
Note that PRIdPTR is considered as linux-ism so it's not available on platforms
like Solaris, although some other free Unix(-like) OSes apparently supports
it too.
---
includes/mkDerivedConstants.c | 11 +++
1 files changed, 11 insertions(+), 0
Note that PRIdPTR is considered as linux-ism so it's not available on platforms
like Solaris, although some other free Unix(-like) OSes apparently supports
it too.
---
includes/mkDerivedConstants.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/includes/mkDerivedConstants.c
in
(even temporarily!) just to unbreak builds on Solaris. Once this is
done, I'll be able to continue with reseting solaris buildbot zone etc.
Thanks!
Karel
On 11/ 8/12 10:04 PM, Karel Gardas wrote:
Note that PRIdPTR is considered as linux-ism so it's not available on platforms
like Solaris
I'm stupid fool here. Indeed, Solaris also supports this and I've been
mislead by few seconds googling around. I'll provide corrected patch asap.
Thanks a lot for this correction!
Karel
On 11/ 9/12 11:34 AM, Gabriel Dos Reis wrote:
On Thu, Nov 8, 2012 at 4:58 PM, Ian Lynaghig...@earth.li
On 11/ 9/12 11:34 AM, Gabriel Dos Reis wrote:
commit 71f7ab6a05448e48a3b5741bb8a5ef57701e9c70
Author: Karel Gardaskarel.gar...@centrum.cz
Date: Thu Nov 8 22:04:44 2012 +0100
define own version of PRIdPTR on platform where its not available
Note that PRIdPTR is considered as
On 11/ 9/12 06:53 PM, Gabriel Dos Reis wrote:
Includeinttypes.h before all other standard headers.
I I understand your standard headers well, then this is already done
in mkDerivedConstants.c, see:
[...]
#define PROFILING
#define THREADED_RTS
#include PosixSource.h
#include Rts.h
On 11/ 9/12 08:33 PM, Gabriel Dos Reis wrote:
On Fri, Nov 9, 2012 at 12:18 PM, Karel Gardaskarel.gar...@centrum.cz wrote:
On 11/ 9/12 06:53 PM, Gabriel Dos Reis wrote:
Includeinttypes.h before all other standard headers.
I I understand your standard headers well, then this is already
86 matches
Mail list logo
