#1526: -fobject-code is ignored for interactive compilation
-----------------------+----------------------------------------------------
Reporter: sorear | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.7
Severity: normal | Keywords:
Difficulty: Unknown | Os: Unknown
Testcase: | Architecture: Unknown
-----------------------+----------------------------------------------------
While looking to see if I could easily fix #1525 myself, I saw a
suspicious modification to the unboxed tuples error; examining more
closely:
{{{
[EMAIL PROTECTED]:~/qhc/qhc-desugar/Qhc/TypeCheck$ ghci
Loading package base ... linking ... done.
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.7.20070612, for
Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Prelude> :set -fglasgow-exts
Prelude> let foo x y = (# x, y #)
Error: bytecode compiler can't handle unboxed tuples.
Possibly due to foreign import/export decls in source.
Workaround: use -fobject-code, or compile this module to .o separately.
Prelude> :set -fobject-code
Prelude> let foo x y = (# x, y #)
Error: bytecode compiler can't handle unboxed tuples.
Possibly due to foreign import/export decls in source.
Workaround: use -fobject-code, or compile this module to .o separately.
Prelude>
}}}
so the suggested workaround doesn't actually work. I can certainly
imagine a model of GHC compilation where the NCG doesn't support anonymous
modules; in which case the easiest fix would be to tweak the error
message. But interactive, optimizing, native compilation *does* sound
like a cool and relatively cheap-to-implement feature :)
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1526>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
