id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc	difficulty	ghcversion	platform
816	c-sources get passed to GHC instead of gcc	guest		"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

"	defect	closed	normal		Cabal library	1.8.0.6	normal	duplicate		dagitj@…	unknown