[Hackage] #816: c-sources get passed to GHC instead of gcc

Hackage cvs-ghc at haskell.org
Thu Mar 17 10:31:26 CET 2011


#816: c-sources get passed to GHC instead of gcc
----------------------------+-----------------------------------------------
  Reporter:  guest          |        Owner:         
      Type:  defect         |       Status:  new    
  Priority:  normal         |    Milestone:         
 Component:  Cabal library  |      Version:  1.8.0.6
  Severity:  normal         |     Keywords:         
Difficulty:  unknown        |   Ghcversion:         
  Platform:                 |  
----------------------------+-----------------------------------------------
 I realize this may be hard to fix and only rarely a problem, but I think
 it's worth creating a ticket to track it.

 Files specified as c-sources are handed to GHC instead of gcc.  This is
 normally fine, but there are times when a file that gcc could handle is
 rejected by GHC.  For example, .m files are rejected by GHC because it
 thinks they are linker scripts but gcc accepts them as objective-c.  See
 for example this ticket: http://hackage.haskell.org/trac/ghc/ticket/5025

 It's not a common problem, but when you do bump into it, it's a HUGE pain
 to work around and leaves you as a user with a sense of being artificially
 limited by your build system.  The pain is exacerbated because the work
 around seems to require that you:

   * Build the c-sources that GHC won't accept using some other means, say
 a makefile, and build it into libfoo.a
   * Switch to Build-type: Custom
   * Then you have to modify Setup.hs to call your makefile during an early
 step such as preConf
   * Then you need copy and postInst steps that put libfoo.a in a place
 where it can be found when building things that depend on your package.
   * With newer GHCs you need to add --force during the package
 registration because the "extra" library will technically have a relative
 path and ghc-pkg doesn't like this (for a good reason, I assume).
   * 'cabal sdist' will complain unless you are careful (read: sneaky).

 All of the above can be done, but it's a lot of work for something that
 could be very simple.  For a working example see this package:
 http://hackage.haskell.org/package/GLFW-b-0.0.2.3

-- 
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/816>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects



More information about the cabal-devel mailing list