
I'll try to make it short. I'm developping a package wich imports C functions. the fact is that when I try to compile if I call the compiler in the usual way, using -package and -llib it gives an undefined reference error... For example if I use: $ghc -package PKGname-PKGversion -fffi -o main Main.hs -llib it gives an error message (undefined references of objects from PKG to functions in lib) but if I use: $ghc -fffi -o main Main.hs -llib /path/to/PKGlib.a it compiles correctly. and also when I do: $ghc -package PKGname-PKGversion -fffi -o main Main.hs /path/to/lib.a it compiles correctly. I know that it is surely my mistake but I didn't find anything helpful in docummentation or in FFI list. I know that I should send this message to ffi mailing list but it is kind of stopped and I think I'll get my answers here... Thank you for the atention.

Frederico, Have you tried using Green Card? http://haskell.org/greencard/ It is basically a foreign function pre-processor for Haskell. It allows your Haskell programs to interface with C libraries in a very straight forward way. Chris. On 9 Feb 2006, at 02:08, Frederico Franzosi wrote:
I'll try to make it short.
I'm developping a package wich imports C functions.
the fact is that when I try to compile if I call the compiler in the usual way, using -package and -llib it gives an undefined reference error...
For example if I use: $ghc -package PKGname-PKGversion -fffi -o main Main.hs -llib
it gives an error message (undefined references of objects from PKG to functions in lib)
but if I use:
$ghc -fffi -o main Main.hs -llib /path/to/PKGlib.a
it compiles correctly.
and also when I do:
$ghc -package PKGname-PKGversion -fffi -o main Main.hs /path/to/lib.a
it compiles correctly.
I know that it is surely my mistake but I didn't find anything helpful in docummentation or in FFI list. I know that I should send this message to ffi mailing list but it is kind of stopped and I think I'll get my answers here...
Thank you for the atention. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Christopher Brown Ph.D. Student University of Kent. UK. http://www.cs.kent.ac.uk/people/rpg/cmb21/index.html

On Thu, 9 Feb 2006, Christopher Brown wrote:
Frederico,
Have you tried using Green Card?
It is basically a foreign function pre-processor for Haskell. It allows your Haskell programs to interface with C libraries in a very straight forward way.
From comparison of the two, my impression is that this parrot is dead, and everyone is just too polite to say so. Unfortunately,
I tried it, and managed to get it working to some extent. Then I found out about hsc2hs and the current FFI support in ghc, and I noticed that according to http://www.haskell.org/greencard/ , the current version of Green Card is an alpha release from 2003. this inability to pull the shades on Green Card, Haskell Direct, etc., takes away a little from ghc's outstanding FFI. Donn Cave, donn@drizzle.com

On Thu, 2006-02-09 at 09:27 -0800, Donn Cave wrote:
On Thu, 9 Feb 2006, Christopher Brown wrote:
Frederico,
Have you tried using Green Card?
It is basically a foreign function pre-processor for Haskell. It allows your Haskell programs to interface with C libraries in a very straight forward way.
I tried it, and managed to get it working to some extent. Then I found out about hsc2hs and the current FFI support in ghc, and I noticed that according to http://www.haskell.org/greencard/ , the current version of Green Card is an alpha release from 2003.
From comparison of the two, my impression is that this parrot is dead, and everyone is just too polite to say so. Unfortunately, this inability to pull the shades on Green Card, Haskell Direct, etc., takes away a little from ghc's outstanding FFI.
There is also c2hs which is well supported and is used for several large C bindings: http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ It works at a higher level than hsc2hs and can make writing bindings quite a bit simpler and cleaner. For example the cairo bindings use it: http://darcs.haskell.org/gtk2hs/cairo/Graphics/Rendering/Cairo/ see the various .chs files, for example: http://darcs.haskell.org/gtk2hs/cairo/Graphics/Rendering/Cairo/Internal/Draw... Duncan

Hello Duncan, Thursday, February 09, 2006, 8:45:01 PM, you wrote: DC> There is also c2hs which is well supported and is used for several large DC> C bindings: there is also hsffig by Dmitry Golubovsky. we need to establish FFI page on the wiki and give at least links to all this packages and small info about using FFI with ghc/hugs -- Best regards, Bulat mailto:bulatz@HotPOP.com

Hello Frederico, Thursday, February 09, 2006, 5:08:12 AM, you wrote: FF> I'm developping a package wich imports C functions. it depends on the details of your use. things go far away from the times where FFI addendum was published, but there is no good docementation, afaik. first, there are a number of FFI-helper packages, that are directed to simplify use of additional features, such as importimg constans, enums, structures, i.e. things not in FFI standard second, GHC nowadays can much easier use C functions. i personally do the following: ghc -c module.c ghc --make main.hs module.o and use module.h with usual declarations of function types while the main.hs contains import staements like the foreign import ccall unsafe "module.h __w_stat_ctime" wst_ctime :: Ptr CWStat -> IO CTime foreign import ccall unsafe "module.h __w_stat_atime" wst_atime :: Ptr CWStat -> IO CTime here< C functions __w_stat_ctime and __w_stat_ctime imported with giving them in Haskell program names wst_ctime and wst_atime. hope it will help. if not - give us additional details about your usage of FFI. -- Best regards, Bulat mailto:bulatz@HotPOP.com

On 2/9/06, Frederico Franzosi
I'm developping a package wich imports C functions.
For example if I use: $ghc -package PKGname-PKGversion -fffi -o main Main.hs -llib
it gives an error message (undefined references of objects from PKG to functions in lib)
I don't have exact answer, but ghc uses ld under the hood and sometimes the order of libraries on ld command line matters. Here's few things that might be useful if that's the case. Use ghc -v and find final link ld/gcc (I don't recall which one ghc invokes for linking) and try that line yourself, you can also move libraries up on list etc to find what order you actually need. Add -llib to the options in package.conf as a library- try adding as first and try adding as last. Try both ;-) Try adding as object file, ie /path/to/lib.a Order of arguments on ghc command line doesn't matter so much, because ghc will put (if I recall correctly) package libraries first and then add -llib and such options to the end on the ld command line- so it's pretty hard to work around the problem just by invoking ghc different way.
$ghc -fffi -o main Main.hs -llib /path/to/PKGlib.a
it compiles correctly.
and also when I do:
$ghc -package PKGname-PKGversion -fffi -o main Main.hs /path/to/lib.a
If I were to guess these work because /path/to/lib.a is handled as an object file, which is somehow different from being library. I have no knowledge what and why there is this sort of magic restrictions. HTH, -Esa

Frederico Franzosi wrote:
I'll try to make it short.
I'm developping a package wich imports C functions.
the fact is that when I try to compile if I call the compiler in the usual way, using -package and -llib it gives an undefined reference error...
For example if I use: $ghc -package PKGname-PKGversion -fffi -o main Main.hs -llib
it gives an error message (undefined references of objects from PKG to functions in lib)
but if I use:
$ghc -fffi -o main Main.hs -llib /path/to/PKGlib.a
it compiles correctly.
It looks like -llib is appearing earlier on the linker's command line than the library from your package, when you use -package. You haven't specified a dependency between the two, so GHC is making an arbitrary choice. The right way to fix this, if your package depends on a library, is to include that library in the "extra-libraries" field of the package. Cheers, SImon

Thank you Simon...
That was just what I needed...
Short and simple.
I would like also to thank all for the answers. That will be surely
helpful too, if not for me, maybe for someone else.
On 2/9/06, Simon Marlow
Frederico Franzosi wrote:
I'll try to make it short.
I'm developping a package wich imports C functions.
the fact is that when I try to compile if I call the compiler in the usual way, using -package and -llib it gives an undefined reference error...
For example if I use: $ghc -package PKGname-PKGversion -fffi -o main Main.hs -llib
it gives an error message (undefined references of objects from PKG to functions in lib)
but if I use:
$ghc -fffi -o main Main.hs -llib /path/to/PKGlib.a
it compiles correctly.
It looks like -llib is appearing earlier on the linker's command line than the library from your package, when you use -package. You haven't specified a dependency between the two, so GHC is making an arbitrary choice.
The right way to fix this, if your package depends on a library, is to include that library in the "extra-libraries" field of the package.
Cheers, SImon
participants (7)
-
Bulat Ziganshin
-
Christopher Brown
-
Donn Cave
-
Duncan Coutts
-
Esa Ilari Vuokko
-
Frederico Franzosi
-
Simon Marlow