Re: [Haskell-cafe] GHC linking problems

[SevenThunders]

Did I find a bug cabal?
I have attempted to fix the problem 

Main.c:(.text+0x22): undefined reference to `__stginit_ZCMain'

by compiling my Haskell library using the flag -no-hs-main.  One would think
that this would make sense if the library is to be used by an external C
program.  However I am using cabal to build the haskell library and I
immediately run into a problem.  My netsim.cabal file looks like

Name:   Netsim
Version:1.1
License:AllRightsReserved
Exposed-modules:
Matrix, Parsefile, PowCDF
Build-Depends:  
base, regex-compat=0.71, parsec=2.0
Extensions: ForeignFunctionInterface
Includes:   matrixstack.h
Install-includes: matrixstack.h, TunePerf.h 
Include-dirs:   ../matrixstack, /usr/lib/ghc-6.6.1/include, .
Extra-libraries: netsimc, matrixstack, lapack, ptcblas, atlas
Extra-lib-dirs: /usr/local/atlas/lib, ., ./phymake,../matrixstack
Ghc-options: -fglasgow-exts -O2 -no-hs-main

My setup.hs file looks like:
import Distribution.Simple
main = defaultMainWithHooks defaultUserHooks

When I build this using
runhaskell Setup.hs build 
all the source files compile just fine, but then a screwy thing happens. 
Cabal attempts to build an executable called a.out. Moreover a.out has no
main of course and it does not attempt to link to any of the libraries in
the Extra-libraries field.
This kills the cabal build.  So trying to link a.out (which it shouldnt be
doing) gives me the errors,
Preprocessing library Netsim-1.1...
Building Netsim-1.1...
Linking a.out ...
dist/build/Matrix.o: In function `Netsimzm1zi1_Matrix_zdwccall_info':
ghc6835_0.hc:(.text+0x1ea9): undefined reference to `PmatC'
dist/build/Matrix.o: In function `Netsimzm1zi1_Matrix_zdwccall1_info':
ghc6835_0.hc:(.text+0x1f79): undefined reference to `Pmat'
dist/build/Matrix.o: In function `Netsimzm1zi1_Matrix_zdwccall2_info':
...
/usr/lib/ghc-6.6.1/libHSrts.a(Main.o): In function `main':
Main.c:(.text+0x22): undefined reference to `__stginit_ZCMain'
Main.c:(.text+0x43): undefined reference to `ZCMain_main_closure'

If I eliminate the -no-hs-main flag in Ghc-options  no attempt is made to
creat a.out, which is as it should be and the library builds without
complaint.  This seems like a bug in cabal.
-- 
View this message in context: 
http://www.nabble.com/GHC-linking-problems-tf4270650.html#a12206722
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] GHC linking problems

[SevenThunders]

SevenThunders wrote:
 
 I have a large Haskell/C project that needs to be linked against an even
 larger set of C libraries and object files  (OpNet) on a linux box (Fedora
 Core 7).  So far I have been able to link my Haskell libraries to some C
 test code containing a main function without incident.  However the link
 flags are very complex having been extracted from ghc.  (e.g. it requires
 a host of -u flags and then a bunch of links to external C libraries
 including a long list of Haskell libraries.)  
 
 Unfortunately control over the OpNet compilation and linking process is
 weak at best.  Moreover it is not clear how the linking occurs and there
 is some suspicion that it ultimately creates a dynamic link library which
 it loads from some external process  (the exact calls to gcc are hidden). 
 During the OpNet build we get the following error
 
 /usr/lib/ghc-6.6.1/libHSrts.a(Main.o): In function `main':
 Main.c:(.text+0x22): undefined reference to `__stginit_ZCMain'
 Main.c:(.text+0x43): undefined reference to `ZCMain_main_closure'
 collect2: ld returned 1 exit status
 
 I do not get this error when statically linking my libraries to a
 standalone C function containing a main() function.  What should I look
 for?  Are there known work arounds to this problem?  It's troubling that
 exporting Haskell to C should be this problematic.  Unfortunately I can
 not use ghc to compile the OpNet code as you might imagine.
 

Does this error occur because of dynamic linking?  That is if this were all
packed into some library without a main function in C it would try to link
to the Main.o object file in libHSrts.a, which has some unsatisfied links
since there is no main function in the Haskell code.  So does static linking
always fix this?  Is it possible to fix it by providing a dummy main
function in a dynamic link library?  I don't know if the latter is possible
in linux.

-- 
View this message in context: 
http://www.nabble.com/GHC-linking-problems-tf4270650.html#a12171221
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe