Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Can't build with cabal install #12

GoogleCodeExporter opened this Issue Mar 14, 2015 · 10 comments


None yet
1 participant
$ cabal install


Warning: the following files would be used as linker inputs, but linking is
not being done: HOC_cbits.o
ghc: no input files
Usage: For basic information, try the `--help' option.
cabal: Error: some packages failed to install:
HOC-1.0 failed during the building phase. The exception was:
exit: ExitFailure 1

$ cabal --version
cabal-install version 0.6.0
using version of the Cabal library 

$ uname -a
Darwin Celebrian.local 9.5.0 Darwin Kernel Version 9.5.0: Wed Sep  3
11:29:43 PDT 2008; root:xnu-1228.7.58~1/RELEASE_I386 i386

Original issue reported on code.google.com by JeanPhil...@gmail.com on 31 Dec 2008 at 3:41

This is the same problem I ran into while trying to fix Issue 10.  The "quick 
fix", if possible, is to use ghc <6.10.  A 
slightly less quick workaround is to remove the 'c-sources' line in the .cabal 
file and manually link HOC_cbits.o into the 
build product (both the .a and the .o).

The primary cause is that the HOC_cbits.o object file is listed as a C source 
file, causing ghc 6.10 to complain loudly 
(stopping the build process) that there are no input files when 'ghc -c' is 
called for it.  Earlier versions of ghc silently 
ignore it and report success.

The deeper cause (the reason it's being done that way) is that it is a 
reasonably simple way of getting Cabal to accept 
an object file as an input to the build process.  Just removing the offending 
line won't work unless we also cause it to 
be linked in to the build products (presumably in a post-build hook in the 
Setup file).

If no-one else picks this up I'll get to it, but I don't know when that may be. 
 I'm not much of a cabal wizard though, so 
if anyone has any pointers I'm happy to hear them.

Original comment by james.c...@usma.edu on 2 Jan 2009 at 2:04

  • Added labels: Component-Build
I'm attempting the second workaround (using ghc 6.10.1). What am I doing wrong?

$ ghc -package template-haskell -package base- -package unix -package 
mtl \
       -framework Foundation HOC_cbits.o HSHOC-1.0.o libHSHOC-1.0.a

Undefined symbols:
  "_ZCMain_main_closure", referenced from:
      _ZCMain_main_closure$non_lazy_ptr in libHSrts.a(Main.o)
  "___stginit_ZCMain", referenced from:
      ___stginit_ZCMain$non_lazy_ptr in libHSrts.a(Main.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status

Original comment by its...@gmail.com on 13 Jan 2009 at 12:48

There are 2 ways I've found to achieve that goal.  One is to run 'cabal build 
-v' with the modified HOC.cabal (no c-sources line), noting the 
'ld' and 'ar' commands executed, copying, pasting and adding 
dist/build/HOC_cbits.o to both commands.  Then mv dist/build/HSHOC-
1.0.o.tmp dist/build/HSHOC-1.0.o before running cabal install.

Another solution I came up with is to (temporarily!) modify the ghc script 
($prefix/bin/ghc) - removing the 'exec' from the last line and 
adding 'true' on the line after, so that no matter what happens inside GHC it 
reports success to cabal.  Then, just build with an unmodified 
HOC.cabal (ie, with the c-sources line).

Obviously, neither of these is a "good" solution, but they both seem to work.

Original comment by james.c...@usma.edu on 13 Jan 2009 at 2:31

You'll also need to pull the latest update to the interface generator (pushed a 
few seconds ago) to be able to 
build the bindings.

All it does is makes sure the generated cabal files have "<4" in their "base" 

Original comment by james.c...@usma.edu on 13 Jan 2009 at 4:56

I'm trying to build from svn.

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.1

$ system_profiler
System Version: Mac OS X 10.5.6 (9G55)
      Kernel Version: Darwin 9.6.0

When I try to 
$ autogen.sh
$ ./configure
$ make && make install

I get:
+ Control.Exception errors (because of base 4.0)
+ linkage errors (HOC_cbits.o not used because not linking or something)

The attached patch lets me build with base 4.0.0 (using Control.OldExceptions) 
with some hand-tweaking of 
$ ./configure OBJCFLAGS='-arch i686' CFLAGS='-arch i686' LDFLAGS='-arch i686'  
CFLAGS='-fpic -dynamic' OBJCFLAGS='-fpic -dynamic' LDFLAGS='-fpic -dynamic 
$ make
(will build HOC_cbits and HOC, then fail)

copy libHOC_cbits.dylib to ~/.cabal/lib (or elsewhere in my ghc-pkg config 
library path)
$ cabal configure && cabal build && cabal install
(make sure HOC_cbits is an extra library in ghc-pkg's HOC package descriptor)
$ cd Bindings
$ sh ./make-bindings-macos.sh
$ ghc-pkg list 
    EdisonAPI-1.2.1, EdisonCore-, GLUT-, GoogleChart-0.2,
    HAppS-Data-0.9.3, HAppS-IxSet-0.9.3, HAppS-Server-,
    HAppS-State-0.9.3, HAppS-Util-0.9.3, HDBC-1.1.6,
    HDBC-postgresql-, HDBC-sqlite3-, HGL-,
    HJavaScript-0.4.4, HOC-1.0, HOC-AppKit-1.0, HOC-Cocoa-1.0,
    HOC-CoreData-1.0, HOC-Foundation-1.0, HOC-QuartzCore-1.0,
    HTTP-3001.1.3, HTTP-4000.0.1, HTTP-4000.0.3, HTTP-4000.0.4,
    HaXml-1.13.3, HaXml-1.19.4, MemoTrie-0.4.1, MemoTrie-0.4.3,
    MonadRandom-0.1.3, OpenAL-, OpenGL-, SDL-0.5.4,
    Stream-0.2.6, TypeCompose-0.6.3, TypeCompose-0.6.4, Vec-0.9.5,

Original comment by kevinwvf...@gmail.com on 27 Jan 2009 at 6:44


If you remove the c-sources line, then the following lines automatically build 
using cabal (at least for me).

cabal configure
cabal build -v2 | grep '\(ar\|ld\) ' | grep -v 'build ' | sed 's,$,
dist/build/HOC_cbits.o,;s,\.o\.tmp,.o,' | sh
cabal copy
cabal register

Original comment by grd...@gmail.com on 28 Jan 2009 at 1:44

Is anyone working on the Cabal files for this?  If not, I'm glad to take it on; 
got a bit of experience working with custom hooks.

Original comment by richardh...@gmail.com on 15 Mar 2009 at 7:58

Here is the bug ticket on cabal side:

I cannot find time to dig into it and am glad if you make it.

Original comment by kaz...@gmail.com on 15 Mar 2009 at 9:42

Sure thing.  I have some time I can devote to it this weekend.  Can you set me 
as the owner of the bug?

Original comment by richardh...@gmail.com on 18 Mar 2009 at 5:06

Should be fixed by r388.

Original comment by aut...@gmail.com on 12 Aug 2009 at 2:02

  • Changed state: Fixed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment