I notice that speed from code generated by -fasm and -fvia-C isn't significant, furthermore -fvia-C takes longer time. So, why ghc still needs gcc (at least on Windows)? -- View this message in context: http://www.nabble.com/Is--fvia-C-still-needed--tp19663119p19663119.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.
Jason Dusek wrote:
Without GCC, how would we compile C extensions?
I'm not sure what you mean. To answer the original question: yes, -fvia-C is almost redundant. We took some steps in 6.10.1 to make -fvia-C behave in a way more consistent with -fasm (that I still need to document properly!), so -fvia-C no longer includes any header files when compiling the generated C code. If you were using -fvia-C to call C functions defined as CPP macros via the FFI, then you can't do that any more in 6.10.1. You have to write a C wrapper function and call that instead. I think -fvia-C generates slightly faster code in some cases, but it might also generate slower code sometimes. FWIW, we still use it for our binary distributions, but I haven't measured the difference it makes, if any. Cheers, Simon
I understood the OP's closing remark -- "...why ghc still needs gcc (at least on Windows)?" -- as a suggestion that GHC on Windows would be better served by not bundling GCC. However, I'm probably not the only one who's written a little C to go along with a lot of Haskell -- and it's nice that the default Windows distribution supports that code (unlike some other type-inferring, statically typed, strongly typed languages, which ship with a little hole to fill in for the C compiler). -- _jsn
The reason why I don't like gcc shipped with ghc distribution is that I waste my harddisk space for two same compilers, only differ in version (I use 4.3.2, ghc ships 3.4.2). And because both are in my PATH, it sometimes behaves unexpectedly. For instance, I try to delete the shipped gcc because I think ghc will be able to find mine (hmm...I suggest ghc implements this, especially for people with low harddisk space). But when I try to compile, it complains about not finding gcc. Crazily, upon compiling with -fvia-C it runs MY gcc, not the shipped one (gcc bindir is placed before ghc bindir in my PATH)! This also happens when I try to bootstrap from source. Second reason, if ghc already performs very well using its ncg, I think it's better to improve it rather than relying on gcc's one. -- View this message in context: http://www.nabble.com/Is--fvia-C-still-needed--tp19663119p19682498.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.
leledumbo wrote:
The reason why I don't like gcc shipped with ghc distribution is that I waste my harddisk space for two same compilers, only differ in version (I use 4.3.2, ghc ships 3.4.2). And because both are in my PATH, it sometimes behaves unexpectedly. For instance, I try to delete the shipped gcc because I think ghc will be able to find mine (hmm...I suggest ghc implements this, especially for people with low harddisk space). But when I try to compile, it complains about not finding gcc. Crazily, upon compiling with -fvia-C it runs MY gcc, not the shipped one (gcc bindir is placed before ghc bindir in my PATH)! This also happens when I try to bootstrap from source. Second reason, if ghc already performs very well using its ncg, I think it's better to improve it rather than relying on gcc's one.
If GHC isn't using its own gcc, that's a bug. We could theoretically ship a cut-down GHC bundle with no gcc, but as others have said it's often useful. For example, hsc2hs needs it, and you'll need a gcc if you write 'foreign export' or 'foreign import "wrapper"' anywhere in your source code. Cheers, Simon
The reason why I don't like gcc shipped with ghc distribution is that I waste my harddisk space for two same compilers, only differ in version (I use 4.3.2, ghc ships 3.4.2). And because both are in my PATH, it sometimes behaves unexpectedly. For instance, I try to delete the shipped gcc because I think ghc will be able to find mine (hmm...I suggest ghc implements this, especially for people with low harddisk space). But when I try to compile, it complains about not finding gcc. Crazily, upon compiling with -fvia-C it runs MY gcc, not the shipped one (gcc bindir is placed before ghc bindir in my PATH)! This also happens when I try to bootstrap from source. Second reason, if ghc already performs very well using its ncg, I think it's better to improve it rather than relying on gcc's one.
If GHC isn't using its own gcc, that's a bug.
We could theoretically ship a cut-down GHC bundle with no gcc, but as others have said it's often useful. For example, hsc2hs needs it, and you'll need a gcc if you write 'foreign export' or 'foreign import "wrapper"' anywhere in your source code.
Having fully-functional-out-of-the-box GHC installers is very useful, but you might be interested in http://hackage.haskell.org/trac/ghc/ticket/1502 which promises to reduce the tension by making GHC's gcc just another gcc (so you'll be more likely to get by with only one gcc) Claus
We could theoretically ship a cut-down GHC bundle with no gcc ...
What about shipping two versions? One with bundled MinGW and other without
Having fully-functional-out-of-the-box GHC installers is very useful ...
Good idea. -- View this message in context: http://www.nabble.com/Is--fvia-C-still-needed--tp19663119p19831381.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.
participants (4)
-
Claus Reinke -
Jason Dusek -
leledumbo -
Simon Marlow