Hi,
I'd like to know wether anyone here is using GHC on OpenBSD *and*
relying on the Haskell-Platform meta package for OpenBSD. If there's
no need for the HP meta package, I could just start to update GHC
and all related packages for OpenBSD, but if there are a lot of
people who prefer to stick
Hi,
On Tue, Nov 27, 2012 at 08:15:59PM +, Ian Lynagh wrote:
Regarding Question 7 (enable dynamic by default on other platforms)
and OpenBSD: as long as it's easy to disable it again, I'll be happy
with *any* decision.
It will be easy to turn it off, but depending on the platform we
On Wed, Jan 04, 2012 at 12:31:23PM +, Joachim Breitner wrote:
One potential problem is that some Linux distributions really don't like
it if you bundle modified versions of external libraries. However, I
just don't see a way around this: [...]
[...]
I guess this means me... Indeed
On Fri, May 27, 2011 at 04:35:17PM +0100, Simon Marlow wrote:
Next best idea is to make GHC use repeatable temporary .c .o file
names for each invocation. There is already a unique temporary
directory where all the the temporary files are created. This suggests
I do not need to worry about
On Wed, Apr 06, 2011 at 08:44:33PM +0200, Matthias Kilian wrote:
I still have to find my noticeses about wether cBooterVersion affects
more than only the ghc lib.
Did a quick test the other day; bootstrapping ghc-7.0.3 from
ghc-6.12.3 with two different VERSION_DATE files. The only visible
://darcs.volkswurst.de/ghc-6.12/ghc:
Sat Apr 24 20:46:21 CEST 2010 Matthias Kilian k...@outback.escape.de
* Zap cBooterVersion, in an attempt to fix #4012
Note: this is obviously just a workaround, not a real fix.
New patches:
[Zap cBooterVersion, in an attempt to fix #4012
Matthias Kilian k
On Tue, Apr 05, 2011 at 09:59:23PM +0530, Joachim Breitner wrote:
Also, the initial upload was built using ghc-6.12.1, while the upload
now is build with ghc-7.0.2. Given that it is a two-stage compiler, I
assume that the output should be identical, but it seems not to be the
case.
Changing
On Tue, Apr 05, 2011 at 08:51:52PM +0100, Simon Marlow wrote:
On Tue, Apr 05, 2011 at 09:59:23PM +0530, Joachim Breitner wrote:
Also, the initial upload was built using ghc-6.12.1, while the upload
now is build with ghc-7.0.2. Given that it is a two-stage compiler, I
assume that the output
Hi,
I'd expect the following program (compiled with ghc and without any
specieal flags) to produce
Just (Exited ExitSuccess)
True
but it produces
Just (Exited ExitSuccess)
False
on Debian Lenny (ghc-6.8), OpenBSD-current (ghc-6.12.3), OpenBSD-current
(ghc=7.0
Hi,
On Thu, Dec 16, 2010 at 06:36:55PM +, Ian Lynagh wrote:
We are pleased to announce the first release candidate for GHC 7.0.2:
http://www.haskell.org/ghc/dist/7.0.2-rc1/
Some random notes for OpenBSD:
- No close look at the test suite results yet, but at least I didn't
notice
On Sat, Oct 30, 2010 at 07:28:40PM +0200, Julien Dessaux wrote:
I'm using the LDAP lib for one of my projects and I found a problem
while building it on an OpenBSD system. It wouldn't compile because there is
a macro named differently in the ldap.h include file. Under linux, this
macro is
On Fri, May 28, 2010 at 10:05:36PM +0100, Simon Marlow wrote:
hReady002(ghci)
== did not investigate yet. failure details below
This one is a known failure right now (I need to clean it up).
Good to know. Thanks for the info.
num009(normal,optc,hpc,optasm,ghci)
== no
On Sun, May 23, 2010 at 07:42:21PM +0100, Ian Lynagh wrote:
We are pleased to announce the first release candidate for GHC 6.12.3:
[...]
Please test as much as possible; bugs are much cheaper if we find them
before the release!
Here are some test results on OpenBSD/amd64, with an 800 MB data
On Mon, Apr 19, 2010 at 02:57:00PM +0100, Simon Marlow wrote:
A few of the tests in the test suite assume a UTF-8 locale, so you're
probably falling foul of that. We could fix the tests - but we do want
to test that the locale encoding is being respected in some way, so just
adding
Hi,
as some of you may know, I'm working on an update of OpenBSDs ghc
port to 6.12.2, currently chasing down the last remaining testsuite
failures. Yesterday, I ran into a problem which I have a fix for,
but only a really ugly fix, and I need some opinions of what users
would prefer.
The problem
Hi,
On Sun, Apr 18, 2010 at 10:53:22AM -0700, Judah Jacobson wrote:
Anyway, the short story is that I have to either hard-code the
character set to something like utf-8, or ghc will start to behave
really strange (for example, ghci would terminate immediately if
you just *type* a
On Fri, Apr 16, 2010 at 04:02:03PM +0900, Jens Petersen wrote:
Just for the record let me report the following build failure for f14
(rawhide):
http://koji.fedoraproject.org/koji/taskinfo?taskID=2107186
[...]
I have reproduced this now also with ghc-6.12.1
inplace/bin/ghc-stage1 -prof
On Wed, Apr 14, 2010 at 08:44:29PM +0200, Matthias Kilian wrote:
module Main(main) where
import System.IO
import System.Process
main = do
hin - openBinaryFile /dev/null ReadMode
hp - runProcess /bin/ls [-l] Nothing Nothing (Just hin)
Nothing Nothing
On Fri, Apr 09, 2010 at 05:48:17PM +0400, Serge D. Mechveliani wrote:
I have tested ghc-6.12.1.20100330 on Debian Linux, i386-family,
on the DoCon test, without profilig.
It looks all right.
Even if I reported to Ian that everything is fine on OpenBSD, I
just found some strangeness with
On Fri, Jan 29, 2010 at 06:10:52PM +0100, Nicolas Martyanoff wrote:
I'm trying to cross-compile GHC as follows:
Host: Linux, x86_64, GHC 6.12.1
Target: OpenBSD 4.6 stable, i386
IMHO, you shouldn't go that way, because it adds much more complexity
than you already have with OpenBSD as host
On Fri, Jan 29, 2010 at 09:42:27PM +0100, Nicolas Martyanoff wrote:
This probably means some type identifier used at that point hasn't
been declared, or macro defined or whatever. You'd have to see
what it is, and maybe it will be more obvious what went wrong.
It seems that SIZEOF_VOID_P
On Sat, Dec 12, 2009 at 05:30:44AM +0200, Thanos Tsouanas wrote:
Up to now I've only used binary versions of GHC, but since
my operating system's (OpenBSD) version of GHC is
lagging behind (currently at 6.6.1), I need to update it.
I tried using my system's ghc-6.6.1 to compile ghc-6.10.4
but
On Sat, Dec 12, 2009 at 09:22:56AM +0100, Karel Gardas wrote:
I somehow managed to first install everything what's required on system
provided 6.6.1 to compile 6.10. I'm not sure if I went step by step
6.6.1-6.8.3-6.10.3 as you try.
No need for 6.8, you can build 6.10 straight with 6.6.
IMHO
On Sat, Dec 12, 2009 at 03:29:09PM +0200, Thanos Tsouanas wrote:
No need for 6.8, you can build 6.10 straight with 6.6.
Ok, I guess I didn't try hard enough..
Probably just
--with-iconv-includes=/usr/local/include \
--with-iconv-libraries=/usr/local/lib
missing to
On Sun, Nov 08, 2009 at 10:19:26AM +0300, Bulat Ziganshin wrote:
seems that wizards are on holiday ATM, so i will help a little - ghc
ports are divided into registerized (working with cpu registers)
and unregisterized (just a C code generated).
I wouldn't touch the *registerized* variant using
On Tue, Sep 22, 2009 at 07:34:53AM -0700, Donn Cave wrote:
I'm thinking it would be expedient to omit Haddock while building a
ghc 6.11 snapshot, per bug ticket #3531
From my basic understanding of its purpose there, that ought to work out
fine - I mean, not to undervalue documentation, but
On Thu, Sep 17, 2009 at 09:17:35AM +0100, Simon Marlow wrote:
Glad you got it going. I notice there are a few test failures, many of
which could be fixed easily, e.g.
--- ./lib/IO/hClose002.stdout.normalisedWed Sep 16 14:08:09 2009
+++ ./lib/IO/hClose002.run.stdout.normalised
On Wed, Sep 16, 2009 at 10:23:58AM +0200, Karel Gardas wrote:
Before going to trace anything I've compared sparky and my setup and it
seems I've had forgotten libiconv library in /usr/local/lib and
LD_LIBRARY_PATH contained this lib. So I've modified LD_LIBRARY_PATH to
exclude /usr/local/lib
On Tue, Aug 18, 2009 at 03:03:43PM +0100, Ian Lynagh wrote:
This is a summary of our plans for GHC 6.12.1.
We are aiming to have the first release candidate out on the 14th
September 2009.
Until then, we plan to focus on the bugs in the 6.12.1 milestone, marked
high priority; they are
On Thu, Aug 06, 2009 at 12:30:51PM +0100, Duncan Coutts wrote:
I've just been informed that unpacking the binary (i386) solaris
distribution using bunzip2 and tar:
It may work better in future if you use a non-GNU tar to pack it up in
the first place. GNU tar uses a non-standard tar format
On Thu, Aug 06, 2009 at 08:54:49PM +0200, Christian Maeder wrote:
Is there something like pax(1) available on solaris? If so, it
should be be preferred, because it's a POSIX tool, so there's some
hope that it behaves the same on different systems.
Yes, pax is available under solaris. I
On Wed, May 06, 2009 at 08:48:04PM +0100, Ian Lynagh wrote:
H Kili,
On Mon, May 04, 2009 at 09:36:00PM +0200, Matthias Kilian wrote:
In your case, it doesn't find libiconv, thus isn't built, and causes
failure later. In my case (a buildbot running OpenBSD-4.5 on i386),
the haskeline
Hi,
On Sun, May 03, 2009 at 11:03:49PM -0700, brad clawsie wrote:
after some trying, i was unable to get the 6.10.3 prerelease to build on
freebsd 7.2. i was trying to use an existing 6.10.2 as my build ghc.
i saved the output of the entire build from ./configure to the point of
failure. it
On Sun, Jan 11, 2009 at 10:36:56PM +0100, Karel Gardas wrote:
A fix from Conal Elliott has already been pushed by Ian.
Indeed! Now compilation aborts on booting testsuite with following output:
make: Entering directory `/buildbot/ghc/kgardas/build/testsuite'
make: *** No rule to make
Hi,
On Thu, Jan 01, 2009 at 11:46:31AM +0100, Matthias Kilian wrote:
pthread_mutex_unlock() is called, evidently from fileLock(), with an
invalid mutex.
NetBSD's pthread implementation differs from Linux in its intolerance
of such things. I have found errors where someone forgets
On Wed, Dec 31, 2008 at 10:44:07PM -0800, Donn Cave wrote:
I tried to build GHC 6.10.1 on NetBSD 4.0 this afternoon, and ran into
an error, where cabal-bin calls the stage2 ghc in utils/installPackage.
pthread_mutex_unlock() is called, evidently from fileLock(), with an
invalid mutex.
On Tue, Nov 11, 2008 at 06:38:02PM +0100, dermiste wrote:
I've successfully built GHC-6.10.1 from 6.6.1 on OpenBSD 4.4, and
would like now to generate a hc-file-bundle to build it without
pre-existing GHC. I followed the instructions in [1], but I'm stuck
with this error :
Linking
On Mon, Sep 29, 2008 at 10:26:35PM +0200, Matthias Kilian wrote:
A full test log is available at
http://openbsd.dead-parrot.de/ghctests/ghc-6.10-openbsd-i386.log
Same for openbsd-amd64, built from sources pulled from the darcs
repository at 15/Oct/2008:13:00:00 +0200:
http://openbsd.dead
On Mon, Sep 29, 2008 at 10:46:34AM +0100, Ian Lynagh wrote:
BTW: I had some problems running the testsuite some weeks ago,
because some autoconf'd stuff was missing. When building from the
repository (*not* from the source tarballs), are there any additional
steps beyond
sh boot
On Mon, Sep 29, 2008 at 07:07:33PM +0200, Matthias Kilian wrote:
And my problem with the testsuite was a PEBKAC (of course): on
OpenBSD, python is installed as python-2.3, python-2.4, python-2.5
(you can have several versions installed in parallel), which isn't
found by configure, which
Hi,
On Mon, Sep 22, 2008 at 01:35:43AM +0100, Ian Lynagh wrote:
We are pleased to announce that the GHC 6.10.0.20080921 snapshot is a
beta release of GHC 6.10.1.
[...]
Please test as much as possible; bugs are much cheaper if we find them
before the release!
Not quite the beta snapshot, but
Hi,
On Tue, Sep 23, 2008 at 03:38:56PM +0200, Christian Maeder wrote:
The error far below is caused by -perm /a+x in mk/bindist.mk
during find:
I've changed it to -perm -111
Unfortunately, this will only find files with the executable bit
set for user, group and owner, so it should be -perm
On Tue, Sep 23, 2008 at 08:34:36PM +0200, Matthias Kilian wrote:
I've changed it to -perm -111
Unfortunately, this will only find files with the executable bit
set for user, group and owner, so it should be -perm +111. However,
even more unfortunately, at least the find(1) on OpenBSD
On Mon, Sep 22, 2008 at 03:32:40PM +0200, Christian Maeder wrote:
I've tried to build a binary dist on x86 under Solaris and did not succeed.
make binary-dist failed with
1.
for FILE in ; do if [ -e $FILE ]; then echo
ghc-6.10.0.20080921/gmp/$FILE
On Wed, Aug 13, 2008 at 09:03:34AM +0100, Simon Marlow wrote:
Yes, it relies only on the Cabal metadata, but the output is a
Makefile only useful for building GHC.
Ok, this statement is plainly not true, since I can use 'cabal makefile'
to build any package outside of the GHC build tree.
On Tue, Aug 12, 2008 at 11:59:37AM +0100, Simon Marlow wrote:
Well, at least the Makefile creation was a step (the first step?)
into the wrong direction, IMHO. I'll run a GHC build to get some
of those generated Makefiles and followup on cvs-ghc, but for a
starter, Cabal shouldn't know
On Tue, Aug 12, 2008 at 10:29:03PM +0200, Matthias Kilian wrote:
Basically, the .cabal file is just converted into some other format
that may be included by another Makefile.
Oops! I again read your (SimonM's) proposal on changing Cabal and
the GHC build system in exactly this way. Sorry
On Wed, May 14, 2008 at 11:35:36AM +0100, Simon Marlow wrote:
for an unregisterised ghc-6.8.2 (or newer), are the .hi files
dependent (except for the 32 vs. 64 bit word size)? I had a quick
look at the stuff in compiler/iface, but the only MD part I found
was that 32/64 bit difference.
The
Hi,
for an unregisterised ghc-6.8.2 (or newer), are the .hi files
dependent (except for the 32 vs. 64 bit word size)? I had a quick
look at the stuff in compiler/iface, but the only MD part I found
was that 32/64 bit difference.
TIA
Ciao,
Kili
ps: if you think this sounds like a
On Mon, Feb 04, 2008 at 12:18:01PM +, Simon Marlow wrote:
Porting is simply broken for various reasons at the moment - in
particular the switch to Cabal for building the libraries broke it. We
knew this at the time, but felt it was more important to make the switch
now and fix
On Wed, Jan 30, 2008 at 08:13:01PM +1100, Manuel M T Chakravarty wrote:
[Philip K.F. Hölzenspies:]
make hc-file-bundle
Making the hc-file-bundle target failed, because not all rts/*.cmm had
rts/*.hc counterparts after the build. The make fails because of this
fragment from the Makefile (part
On Mon, Jan 21, 2008 at 03:23:54PM +, Simon Marlow wrote:
First thing to note is that bootstrapping from HC files has bitrotted in
6.8.x, see http://hackage.haskell.org/trac/ghc/ticket/1346. I've updated
the wiki instructions to say this. You should go back to 6.6.x, or be
prepared to
On Fri, Jan 11, 2008 at 09:32:20AM -0800, Don Stewart wrote:
I have just built and installed ghc-6.8.2 on my linux box but I can't find
the network package. Has it been moved or left out?
It's not installed by default. You can find it on hackage.haskell.org,
On Fri, Jan 11, 2008 at 11:06:57AM +, Jim Burton wrote:
In file included from Stg.h:150,
from Rts.h:19,
from mkDerivedConstants.c:23:
Regs.h:30:45: gmp.h: No such file or directory
For a starter, look at http://hackage.haskell.org/trac/ghc/ticket/2009
No
On Wed, Jan 09, 2008 at 10:41:23PM +, jim burton wrote:
Thanks for that, the configure script gets to the end with that help.
Following the instructions at
http://hackage.haskell.org/trac/ghc/wiki/Building/Porting#PortingGHCtoanewplatform
, I then try to make includes but get a big stream
On Wed, Jan 09, 2008 at 07:42:21PM +, jim burton wrote:
I'm trying to build unregistered 6.8.2 on NetBSD Alpha 2.1.0_STABLE -- I
have the following problem which seems to be same as this one -
http://hackage.haskell.org/trac/ghc/ticket/1860
No, I think it's another problem.
$
On Sun, Jan 06, 2008 at 05:20:18PM +, Ian Lynagh wrote:
Prologue junk?: .type s32x_ret, @function
s32x_ret:
pushl %ebp
movl%esp, %ebp
I see nearly the same problem with ghc-6.8.2 on OpenBSD, using the
gcc-3.3.5 included in its base system.
[Note: already shortly discussed with Wilhelm]
On Fri, Nov 23, 2007 at 12:30:06PM +, Wilhelm B. Kloke wrote:
../../compiler/stage1/ghc-inplace -package-name unix-2.2.0.0
-hide-all-packages -i -idist/build/autogen -idist/build -i. -Idist/build
-Iinclude -#include HsUnix.h -#include
On Tue, May 29, 2007 at 04:15:29PM +0100, Simon Marlow wrote:
What puzzles me a little bit is the fact that this does *not* happen
on amd64 (aka x86_64) but only on i386 so far.
So does this ring a bell for anyone? I didn't find anything similar
in the archives or in the bug tracker.
No
Hi,
I'm currently working on updating the GHC port to 6.6.1 for OpenBSD,
and when I run the testsuite (ghc-regress), all test cases for the
way threaded1, i.e. debug + threaded bail out with an assertion
failure:
Blocks: 132 live + 123 free = 255 total (508 around)
conc010: internal error:
On Fri, May 04, 2007 at 02:48:13PM +0200, Christian Maeder wrote:
How or where can I pick up the testsuite for this new version? I want to
test my own builds.
http://www.haskell.org/ghc/dist/6.6.1/ghc-testsuite-6.6.1.tar.gz
___
Glasgow-haskell-users
Hi!
I hope this isn't a FAQ, but AFAIR this hasn't been asked in the past:
Are there plans to replace the ghc frontend (driver), which is currently
written in perl, by a version implemented in Haskell?
I know that perl is nice for fiddling with command line options, but on
the other hand, it's
Hi!
I wonder what the cvs release naming strategy is. Ist 4.06 on the main cvs
branch, or is there a special tag for official releases, or what else?
A `cvs up -dPA -r 4.06' in the fptools directory simply removed everything
(don't worry, I did make a copy before the update).
Bye,
Kili
The best thing to do is use the anoncvs repository, and just 'cvs update' to
get the latest patches. If you're running over a phone line then it might
help to make ssh do some compression.
Yes, but this requires at least one complete checkout. Of course, after
this is done, cvs update will
Perhaps the same is happening with GHC's RTS. You can ask gcc-2.95 to
be less aggressive by using -fno-strict-aliasing (I think; consult
the documentation). I'd be interested to hear if this makes any
difference.
I've already tried this with no success. However, it seems that during the
make
Thank you all for your tips.
I've compiled first ghc-3.02 using the .hc files and then ghc-4.02 which
required an additional -dcore-lint on the following files:
compiler/rename/ParseIface.lhs
lib/exts/Int.lhs
lib/exts/Word.lhs
lib/posix/PosixTTY.lhs +
lib/std/PrelArr.lhs
lib/std/PrelHandle.lhs
66 matches
Mail list logo
