=
The (Interactive) Glasgow Haskell Compiler -- version 6.2.2
=
A Mac OS X double-clickable package is now available at:
Now, some of the most common operations used in dynamic web pages
relate to directory listing/manipulation. I was happily thinking that
System.Directory would provide the needed functionality. Indeed it
does, but unfortunately setCurrentDirectory breaks the thread
abstraction.
What I mean is that
Benjamin Franksen wrote:
main = let ?b = True in use_b
--use_b :: (?g::Bool) = IO ()
use_b = print ?b
It isn't: ghc -fimplicit-params says
Unbound implicit parameter (?b :: a)
arising from use of implicit parameter `?b' at TestBug.hs:4
In the first argument of `print', namely `?b'
The hook idea works with static linking: the RTS provides a default
version of the hook, that can be overriden by a user-supplied function
of the same name. This is what GHC does. However, our dynamic linker
doesn't support this kind of overriding. The system's dynamic linker
does, though:
The temporary file is
created but it is empty. It seems like the stdout/stderr handles are
flushed in GHC.TopHandler.runMainIO but only if the program terminates
without exception.
Should be fixed now; when terminating using exitWith, the handles are
now flushed.
Note that they are still not
It seems they should always be flushed. certainly if a program fails
via
'fail' in IO or 'error' as these are common ways for programs to report
an error and losing output would definitly be counter intuitive and
make
it quite tricky to debug. especially when you can't flush stdout before
So I guess I can't really use them in code that's supposed
to be portable among different platforms?
Maybe 'forkOS' combined with calling poll() through FFI
really is the best solution? I seem to recall reading
somewhere that the threaded RTS was more efficient for these
applications anyway?
Two
Thanks, good to know; I'll read through 10.2 more carefully. I didn't
think I'd need to cross-compile x86-linux to x86-linux.
You don't need to - the recommended way is to download a binary
version. If you don't like using binary distributions, then use it for
bootstrapping only, i.e. use it
Hi
I got ghc-6.5 prerelease from the CVS and managed to get it up and
running, *except* for ghci, the interactive part.
It worked last time I tried.
Is there something in particular that I need to think about to make
ghci support get compiled into ghc?
When using ghc-inplace, make sure you're
Brian Strand wrote:
I originally tried the binary distribution but ran into library
issues. That is of course the obvious path to try, and try it I did.
Rather than going straight to installing deprecated libraries, I tried
to provide some feedback on ghc (especially since 6.4 RCs are out).
During my ongoing research on doing whatever I feel like, I
discovered that using C++ libaries in GHCi (no problems with GHC)
wasn't as pleasant as I had hoped.
Apparently C++ sources requires to be linked with crtbegin.o and
crtend.o (and others?) and I was wondering how to solve this nicely.
Any
I've written a binding to a C++ library where I use a simple wrapper
file to overcome the name mangling (extern C functions calling C++,
nothing fancy). Is there a way to make that more GHCi friendly or
should I explore other options?
What exactly is going wrong?
Try wrapping your binding in a
[...]
warning: don't know how to split object files on this architecture
[...]
Wolfgang, Ryan - that looks like a splitter problem, no?
Definitely. Looks like there is no splitter for x86-64. SplitObjs=NO is
definitely required.
(The splitter is more of a dark art than the evil mangler, I
I've uploaded a Mac OS X installer based on the stable tree from March
2nd + the patches I committed yesterday at:
http://opeongo.cas.mcmaster.ca/~wolfgang/GHC-6.4.20050302.pkg.zip
This package is built with support for dynamic libraries (some human
intervention was required to build it).
Mac
On 4-Mar-05, at 11:57 AM, Simon Marlow wrote:
Don't hold your breath, I have some bad news. It seems that gcc is
still generating incorrect code for register variables (or maybe it's
broken again?).
So maybe this will be the first NCG-only port of GHC :-).
Death to the Mangler!
Cheers,
Wolfgang
Another Mac OS X installer:
http://opeongo.cas.mcmaster.ca/~wolfgang/GHC-6.4.20050308.pkg.zip
Features:
*) all the normal GHC 6.4 features
*) dynamic linking
*) nice icons you can double-click to open a terminal window with ghci
(one for H98 and one for -fglasgow-exts)
*) You can even drag your
When I double-click the icon, I get *two* Terminal windows started, one
running ghci, the other just an ordinary shell. Is this intended?
No, that's the Terminal's default behaviour of opening an empty window
when it is launched, before receiving the command to open a new
terminal window and
=
The (Interactive) Glasgow Haskell Compiler -- version 6.4
=
A Mac OS X installer package for Mac OS 10.3 (Panther) is available at
=
The (Interactive) Glasgow Haskell Compiler -- version 6.4
=
A Mac OS X installer package for Mac OS 10.3 (Panther) is available at
=
The (Interactive) Glasgow Haskell Compiler -- version 6.4
=
A Mac OS X installer package for Mac OS 10.3 (Panther) is available at
Hi,
I am trying to make an unregisterised build. As my host machine, i use
a Mac running Mac OS X 10.4. When building ghc 6.2.2 on the host
machine (also running GHC 6.2.2), i get the error attached below
when doing 'make all' in ghc/. Does anyone
have an idea how to solve this ?
thanks,
we have tried long and hard to call Haskell functions from C++ usingthe FFI mechanism but without success. Don't forget to say which platform you're on - the solution might be slightly platform-dependent. $ ghc -fffi Foo.o Foo_stub.o main.cpp main.o(.text+0x22): In function `main': main.cpp:
My GHC 6.4.1 packages for Mac OS X are finally ready.
Mac OS X 10.3.9 (Panther) and 10.4.x (Tiger)
http://www.uni-graz.at/imawww/haskell/GHC-6.4.1.pkg.zip
This is an installer package that will install a full version of GHC
with GHCi, profiling, dynamic linking, double-clickable icons
Another shortcoming is that the native code generator in GHC isn't
capable of dealing with backward jumps to labels (because GHC hasn't
needed that so far). But if you did C-- optimisation, you'd probably
generate such jumps. It'd be great to beef up the native code gen to
handle that.
I'm
On 2-Mar-06, at 7:35 PM, Ashley Yakeley wrote:
Thanks. Now the build process gets stuck here:
I ran into this yesterday, but didn't have time to look into it;
today, ./darcs-all pull seems to have fixed it.
Cheers,
Wolfgang
___
On 4-Mar-06, at 11:07 AM, S. Alexander Jacobson wrote:
Does ghc work on the (intel) macbooks or does it need to be rebuilt?
Will code compiled for the old macs work on the macbooks or does it
need to be recompiled?
Yes and no.
GHC, and programs compiled by it, should run without
On 4-Mar-06, at 3:33 PM, Geoffrey Alan Washburn wrote:
I don't have MacOS X Intel handy to verify, but I was under the
impression that Rosetta was only automagically invoked by the
operating system on application bundles. However, there is a
dearth of information regarding this point
C - adjustor - stub - Haskell - stub - adjustor - CIt could be the case that the adjustor tail-jumps to the stub, but this is not guaranteed to be the case for all platforms.Hmmm, I thought it was.Well, the FFI addendum is rather vague on this point; this seems to be all it says about
Even as the author of some parts of Adjustor.c and some parts of
Hugs' FFI
implementation I have to admit that it isn't clear to me at all if
tail-calls
are used everywhere. %-)
Hugs uses tail-jumps or static return code on all supported
platforms, GHC on all platforms except IA64.
And
On 28-Mar-06, at 4:52 AM, Simon Marlow wrote:
This seems very strange indeed - I immediately suspect something
odd with your hardware. Try swapping out RAM, if you can.
Strange that it only seems to affect Perl (Perl is running the
mangler that generates that .s file). I suppose it's
X (at least I assume he's busy,
that's the last I heard, but he didn't respond to my latest ping).
Oops, sorry about that. Yes, I'm quite busy, trying to get a degree
here.
Proper Mac OS X support will resume on September 1st :-).
So the mantle of powerpc-apple-darwin maintainer is
Could someone on MacOS X try the 6.4.x branch again? I just
committed a fix that makes the threaded RTS more stable on Solaris,
and I'm hoping it clears up the problems on MacOS X too. Remember
to re-enable -threaded in ghc/compiler/Makefile if you previously
disabled it.
The problem
The NeHe tutorials work for me with both GHC 6.6 and HEAD on my Intel
Mac; however, I'm not using MacPorts.
Is anyone else here who uses MacPorts on an Intel Mac, to confirm or
deny the bug?
Cheers,
Wolfgang
___
Glasgow-haskell-users mailing list
On 20-Dec-06, at 10:10 AM, Michael T. Richter wrote:
Well, I'm almost entirely ignorant of LLVM and of Haskell --
especially the internals of both. That makes me ideally suited for
this project since I'm not aware that it's impossible.
I'm afraid LLVM currently lacks some features that
On 21-Dec-06, at 1:26 PM, Michael T. Richter wrote:
Global Register Variables -- I'm not sure I understand the point
here. LLVM is a... well, a virtual machine. It's not a real
target. The LLVM code is then either simulated in a VM (as per,
say, Java) or it is further compiled to a
On 3-Jan-08, at 4:47 PM, Christian Maeder wrote:
Hi,
can someone explain the linking error below? (on Intel-Mac (Tiger?))
Preprocessing library HDBC-sqlite3-1.1.3.0...
Building HDBC-sqlite3-1.1.3.0...
[1 of 7] Compiling Database.HDBC.Sqlite3.Consts ( dist/build/Database/
,
Wolfgang Thaller
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
I realize that you would rather clean things up first, but could I talk
you
into passing on your patches? We could use a build on MacOS X today (and
I
literally mean today)
It's not easy when I say unclean, I _mean_ unclean
However, here it is
I even added a new file in a place where it
I've meanwhile discovered a problem with my GHC compile for PowerPC.
While it manages to compile simple programs and the FFI seems to work (for
my simple test program), many programs compiled by it abort with a message
like:
scavenge_stack: weird activation record found on stack: xx
where xx is
I can't seem to get the Garbage Collector to work properly on MacOS X.
When a program triggers the Garbage Collector, it aborts with the
following message:
a.out: fatal error: scavenge_stack: weird activation record found on stack: 0
The same error happens both in unregistered mode and using my
Some programs work, including green-card and some HOpenGL programs.
GHC, compiled with my registerized version, crashes.
At some point, there is pointer on the Stg Stack that points into data space.
However, it doesn't point to a closure. In points to a place just
after the last data symbol in
After weeks of wrestling with Apple's buggy version of gdb,
registerized compilation on MacOS X finally works!
I've tested it on GHC itself and on my own (H)OpenGL program, VOP,
and it seems to work now.
I'm attaching my patches.
I've had trouble compiling the newest version from CVS.
I'm attaching my patches.
Well, I'm attaching them _now_.
Cheers,
Wolfgang
%ghc-5.03-macosx.patch.gz
Description: application/applefile
ghc-5.03-macosx.patch.gz
Description: Binary data
Here are some new patches for GHC for MacOS X.
The patches are relative to the CVS HEAD from 9th of April.
I also have prepared a binary snapshot [a double-clickable installer
package this time], but as last time, I don't have the webspace to
upload it myself - I'd be happy to FTP it wherever
nothing to do with
MacOS X.
Regards,
Wolfgang Thaller
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
for
Windows include libgmp as a DLL. That's what I'll be doing for my
future releases of GHC for MacOS X.
Cheers,
Wolfgang Thaller
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
On 2002-06-03 12:46:19 +0100 Simon Marlow [EMAIL PROTECTED] wrote:
We really *should* do this, I know. The problem is that it isn't free
by a long shot: it'll make .hc files significantly larger, and obfuscate
a lot of code.
Anyone have any ideas that don't have such a big impact?
Well,
I'm being provocative, I know. I'm not trying to insult though, just to
encourage a creative discussion.
Me too. But I've never seen a flame war on any haskell list, so I trust that no one will be insulted if we present our differing opinions in a strong way. We'll just have to take this
In short, it doesn't work :-( .
OpenGL (at least on MacOS) keeps track of the current context on a
per-thread basis. The GLUT library sets the current context and calls
back to the program. With GHC 5.03 compiled with --enable-threaded-rts,
the callback gets executed in a different thread.
Simon Marlow wrote:
This discussion is getting rather long, so I thought I'd summarise (as
much for my benefit as everyone else's). Please let me know if I get
anything wrong.
I haven't found anything wrong.
I'm pretty sure (1) and (2) aren't viable, though.
I basically agree. In the presence
[04:14pm 0.11 0.15 0.16 ~/CGI]$ ghc Counter.lhs
compilation IS NOT required
Counter.o: In function `__stginit_Main':
Counter.o(.text+0x16): undefined reference to `__stginit_CGI'
[...]
Your invocation of the ghc command is telling GHC to just compile
Counter.lhs to Counter.o and then
, or should I rebuild?
Just check the mailing list:
From: Wolfgang Thaller [EMAIL PROTECTED]
Date: Fre Aug 30, 2002 22:43:34 Europe/Graz
To: GHC List [EMAIL PROTECTED]
Subject: GHC on Mac OS X 10.2 (Jaguar)
The new Mac OS X 10.2 has arrived, and GHC has stopped working.
I've compiled a new
Many platforms have the C++ runtime and the C++ standard library as a
static library (probably because the C++ ABI is not as stable as it
should be...). I think this applies to both Mac OS and to Windows
[mingw32], perhaps it's the same with Solaris.
If that is the case, it would explain the
4.3.
Unpack it, and use the usual commands for building installing GNU
software:
./configure
make
sudo make install
If there are any problems, e-mail me (auf Deutsch).
Cheers,
Wolfgang Thaller
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED
Hello All,
A while ago there was a discussion on the shortcomings of the threaded
RTS (in short, it doesn't work with foreign APIs that use thread-local
state, and that breaks HOpenGL). Back then, it was decided to just keep
the threaded RTS off by default and to do something about it some
I wrote:
[...] Note that the fact that only one Haskell thread may execute at
a
time remains unchanged. [...]
Sven Panne wrote:
I haven't thought very deeply about your proposal yet, but I don't
understand
the remark above: What about e.g. a multi-processor Solaris machine
(where
pthreads
Great, thanks. I hope you'll keep it up to date so that by the time
the
discussion converges it can serve as a specification and rationale. We
can put it in CVS too... Simon will think of where!
Until then, I'll play the role of a human CVS server.
Ultimately it'd be
worth integrating with
Nicolas Oury a écrit:
* I think that, if it is not too much complicated, it could be great
to put many threads in the OpenGL OS thread. The goal of concurrent
Haskell was to allow concurrency for expressivity. It would be a pity
to lose this in part of programs for technical reason. Having
Nice design, Alastair. I've stolen lots of ideas and some text for the
complete rewrite of the proposal. The concept of associating haskell
threads to native threads proved to be a good way of explaining my
original idea in a different way --- and then I found out that
forkNativeThread needn't
Simon Marlow wrote:
I don't see the problem with forking a new Haskell thread for each
foreign export, and associating it with the current native thread if
the
foreign export is marked bound. It does mean we can get multiple
Haskell threads bound to the same native thread, but only one can be
I'll write up a new version of the proposal tomorrow. For now, here are
some answers and [at the end] a question about the current FFI
specification.
Simon Peyton Jones wrote:
You don't say (but you do mean)
A bound Haskell thread can be executed only by its associated
native thread
No I
So, we can say that foreign functions of the form:
foreign import bound unsafe bar :: ...
are illegal or we can allow them and provide warnings or we can allow
them and trust the programmer to know that bar is much more expensive
than they think. (I favour the first two.)
NOOO! Don't do
I've postponed writing up a new proposal again...
But I'm going to sum up some requirements that I would like to see
fulfilled - to make it clearer to others why I'm proposing such strange
things...
*) It should be possible for Haskell code to arrange that a sequence of
calls to a given
as the LGPL places some requirements on
your program that you might not be aware of. If you want to do it
anyway and you need more assistance, just yell.
Regards,
Wolfgang Thaller
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org
Dean Herrington wrote:
[...] Rather, I find it
nonintuitive that calling from Haskell to foreign code and back into
Haskell
should create a new Haskell thread, when these two Haskell threads
really
are just different portions of a single thread of computation
(deliberately vague term).
I
Mac OS X 10.1).
Regards,
Wolfgang Thaller
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
the syntax (# a, b #) for unboxed tuples.
When GHC's language extensions are enabled, GHC parses '(#)' as '(#'
and ')', which doesn't make sense.
Solutions:
1) switch off the language extensions
2) use spaces around the hash: write ( # ) instead.
Cheers,
Wolfgang Thaller
Reto Kramer wrote:
I'm trying to deliver a self contained app that I developed with ghc
5.04.1 on Mac OS X (10.2.2). It all works well if ghc is installed on
the machine, but on a user-machine w/o ghc, the following file is
needed:
HaskellSupport.framework/Versions/A/HaskellSupport
Yes.
before compiling, the Finder
will report an unexpected error (because the Test.app wrapper doesn't
contain a binary).
---
(C) 2003 Wolfgang Thaller
Permission is granted to use it for any purpose you like. It is
provided AS IS, there are absolutely no warranties.
---
Have fun!
Wolfgang
I've been watching the discussion about native threads, and getting
thoroughly confused.
Understandable ;-) .
But before investing effort in fiddling with it, I thought it'd be good
to see whether anyone finds it helpful.
Yes, it does seem to be a good idea.
Feel free to modify it. E.g.
, they don't work.
Instead, try to use:
installHandler sigPIPE Ignore Nothing
I hope that works, I haven't tried it.
Cheers,
Wolfgang Thaller
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell
I'm almost ready to send in a patch that should fix most of the current
issues with the threaded RTS.
But I'm stuck at the problem of terminating the RTS in a proper way.
According to the GHC manual, a concurrent Haskell program should
terminate when the main action terminates. This sounds
Should/can I use rts_eval()?
Yes.
Any pointers on what this does (start new threads, cause garbage
collection
...) would be appreciated. I can (and have) gone over the code but a
more
high level description would be helpful.
rts_eval() may cause garbage collection to happen. This means
GPR13 is indeed considered nonvolatile, so it looks like the JVM is
correct and the function made by createAdjustor is wrong.
Thanks, fixed.
(both in the HEAD and in the stable branch)
I'm beginning to think that the PowerPC has way too many registers (and
Intel still has too few - the good
Can someone add OSX(darwin) to the mk/config.mk.in file?
Done. I had it enabled in my build.mk file and I hadn't noticed that it
wasn't yet on by default. Sorry for wasting your time.
Cheers,
Wolfgang
___
Glasgow-haskell-users mailing list
[EMAIL
I had wanted to CC this to the list, but of course I forgot:
Stephen Pitts [EMAIL PROTECTED] wrote:
Is there an easy way to profile stack usage without rebuilding with
ticky-ticky profiling? I have two implementations of an algorithm;
the one with straight lists seems to use constant stack,
As far as I can tell right now, sendfile is not supported on Mac OS X.
There's no manual page, and it doesn't seem to be in any sytem library.
There is a prototype in sys/socket.h, but it's wrapped in an #ifdef
that's never #defined.
When I last build the HEAD here, I didn't have any problems -
Ahn Ki-yung wrote:
C call blocks the whole process, and Concurret
module become meaningless. Isn't there any
library or wrapper that can avoid ccall from
blocking entire process ?
There is an extension to the GHC runtime system in the CVS version which
addresses this problem, but that means
Seth Kurtzberg wrote:
Is there, or is anyone working on, ports for Mac OSX and/or Mac OS9?
I'm currently responsible for the Mac OS X version of GHC. I'll upload
a GHC 6.0 binary for Mac OS X binary as soon as possible, but I'm short
on time and processor cycles, so it might take a few more
Dear Wolfgang,
I maintain the Hugs port for the darwinports system (a cousin of fink
and
perhaps the successor to the *bsd ports system). I'd like to add a port
for ghc-6.0. I tried to build it but ran into some problems.
1. configure doesn't pass the CPPFLAGS and LDFLAGS environment
variables
I've now uploaded a binary package for Mac OS X
(Apple Installer .pkg inside a .dmg)
at
http://www.uni-graz.at/imawww/haskell/GHC.6.0.dmg
Enjoy!
Cheers,
Wolfgang
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
Hi,
The Haskell Web Server claims that the .dmg file for the MacOS Package
is of type text/plain; some browsers on MacOS (IE and Netscape)
therefore try to display it as plain text instead of downloading it.
Is anyone able to fix that somehow?
Cheers,
Wolfgang
Sean Seefried [EMAIL PROTECTED] wrote:
Dear GHC users on the Mac,
I'm addressing this primarily to Wolfgang but also to anyone who
has built GHC HEAD successfully on Mac OS X.
I'm having difficulty doing it myself and I was just wondering if someone
could put together a small set of instructions
That, along with your HSrts.o later, ties in with the files that change
file size except that /usr/lib/ghc-6.0/package.conf gains a pthread
in
the rts extra libraries.
Ah yes, I overlooked that, because it doesn't happen on Mac OS X :-).
It looks like I want to make a package-threaded.conf that
I'm not sure it's worth making a threaded-rts variant distribution
right
now, given that we'd just throw it away later. But you're welcome to
try.
We might not need the variant business when the new threaded-rts is
finished, but personally, I like the thought of getting the Threaded
RTS
=
The (Interactive) Glasgow Haskell Compiler -- version 6.0.1
=
A Mac OS X package id now available at:
http://www.uni-graz.at/imawww/haskell/GHC.6.0.1.dmg
Cheers,
Peter Strand wrote:
Hi,
I'd like to use a C-library which calls back into the haskell
program, potentially from different threads at the same time.
That is, the following calling sequence takes place:
(haskell) Calls C via foreign import.
(c) Creates threads, which in turn calls back
Dear GHC for Mac OS X Users,
As you probably know, Mac OS X 10.3 a.k.a. Panther is being officially
released today. I'm going to upgrade my Powerbook right away.
Panther adds some new functions in Darwin (for example, dlfcn.h and
proper wchar support). GHC will automatically make use of these
On 25.10.2003, at 00:01, Diederik van Arkel wrote:
Not necessary, the 10.3 dev tools includes the headers for 10.1 and
10.2 so you can compile for all three OS revisions from your 10.3 box.
Well, but those are only easily accessible from Apple's Xcode IDE; I
have no idea how to get the
On 29.10.2003, at 21:15, Gregory Wright wrote:
Hi Wolfgang,
I tried building 6.0.1 on Panther using 6.0.1 built on Jaguar. (The
build was run under
darwinports.) It failed with the following:
[...]
Ever see anything like this before?
Hmm... now that you mention it, probably yes. There was some
Yes I know this is really Apple's fault, but according to
http://developer.apple.com/documentation/ReleaseNotes/DeveloperTools/
GCC3.html
The GCC 3.3 preprocessor inserts a new pragma, #pragma GCC
set_debug_pwd, as part
of the new Distributed Builds feature. (See below.) This may
(follow-ups to the FFI list please)
Rafael Martinez Torres wrote:
HI:
Reading Haskell 98 FFI report, one question arised:
Imported and declared a foreign function , via
foreign import ccall foo:: IO(CInt)
Is it guaranteed to be executed in atomic way ? I mean , should it
block the whole STG
George Russell wrote:
For the development snapshot 6.3.20031201, System.Posix.forkProcess
has the type IO () - IO System.Posix.Types.ProcessID. In 6.0.1
it has type IO () - IO (Maybe System.Posix.Types.ProcessID). Is
this change intentional, and if so how are you supposed to test
after the fork
The (Interactive) Glasgow Haskell Compiler -- version 6.2
A binary package for Mac OS X version 10.3 (Panther) is now available at
On 23.02.2004, at 13:32, MR K P SCHUPKE wrote:
b - mapArray id a
The reason it is slow is because the array type is copied every time
a member is assigned.
The array in question is already a mutable array, and even for
non-mutable arrays, mapArray would use mutable arrays internally.
The
What platform? Does everything work if you remove the -static?
alpha, powerpc and hppa so far. I expect the same will happen for mips
and mipsel.
If, on powerpc, I run the final link command without -static
(that's the
only place it should make a difference, right?) then it links without
warnings
On 09.03.2004, at 15:53, Ian Lynagh wrote:
On Tue, Mar 09, 2004 at 01:04:59AM +0100, Wolfgang Thaller wrote:
So I assume this is on powerpc-linux?
Yup, sorry (and the others are all Linux too).
Ah yes, that -static flag was lurking there from the old AIX port. It's
definitely OK to remove
The (Interactive) Glasgow Haskell Compiler -- version 6.2.1
A Mac OS X 10.3 (Panther) binary installer package is now available at:
Sigbjorn Finne [EMAIL PROTECTED] writes:
Thanks to the hard work of Jeff Lewis, the
CVS pserver at cvs.haskell.org is now back up again,
Malcolm Wallace wrote:
Good, and well done. Unfortunately, ssh-based connections to the
writable repository have now started to fail for me. The ssh server
Is there any chance that GHC 6.04, or any GHC version in the next few
months, will support the following on Windows:
1) use of native threads so that the world won't be stopped every time
you wait for a character;
Should already be in 6.02.1 - add the -threaded flag when linking, and
you'll get
1 - 100 of 102 matches
Mail list logo
