July 2002 - FFI - Haskell.org

RE: Library archives
by Simon Marlow 11 Aug '02

11 Aug '02

> I see a lot of discussion about header files. > I see a small amount of discussion of libraries with many conflicting > suggestions. > I see no _conclusion_. Ok, I can't see the conclusion either, but I seem to recall that at one stage the library specs were removed from the spec altogether and only came back again because of .NET (no, I'm not sure why they're in the C section of the FFI spec either). >From the GHC perspective they're not useful, and it would be headache to implement them if we had to. Fortunately the current spec says that they are a "hint" only, so we don't have to implement them. But that causes problems for anyone wanting to write portable FFI code: by definition, because the interpretation of the lib spec is implementation dependent, it can't be used in portable code. So really, I think it should be removed. If the FFI spec says anything about libraries, IMHO it should say that the methods used to find and link against external libraries are implementation dependent. We as implementers can always get together and agree on a common mechanism (packages, command-line arguments, whatever) to make life easier for the punters. > ps In case it wasn't clear > yesterday, I think the spec should be > clear about whether C libraries live in local or global namespaces. > I propose that they should be in a single global > namespace. This will require no change to GHC but will require a change to > Hugs' historical behaviour. Fine by me. Cheers, Simon

4 3

RE: ffi howto
by jacob colvin 31 Jul '02

31 Jul '02

>From: "Simon Marlow" <simonmar(a)microsoft.com> >To: "jacob colvin" <carbonated_beef(a)hotmail.com>,<ffi(a)haskell.org> >Subject: RE: ffi howto >Date: Tue, 30 Jul 2002 13:47:03 +0100 > > > If someone could post an example of a "hs" and a "c" file and > > how to compile > > it with ghc, i would be very apreciative. I have looked at > > > > http://www.haskell.org/ghc/docs/latest/html/users_guide/sec-ff > > i-ghc.html > > > > for a long time, and I can't figure out how to reproduce the > > example. I > > have noticed that if you name your hs file "M.hs" as the page > > says, then ghc > > will produce M_stub.h instead of the included "foo_stub.h" > > that the c main > > program lists. I've used windowsXP and ghc[rpm] installed on > > redhat7.3, and > > still nothing works. > >The stub files are named after the original .hs file, so if you have >Foo.hs you'll get Foo_stub.c. Most people name their files after the >module name, so for example Foo.hs contains module 'Foo' (in fact this >is necessary if you want to use ghc --make or GHCi). > > > my best linux output... > > [Jacob@localhost ffi]$ ls > > main.c M.hs > > [Jacob@localhost ffi]$ ghc -fglasgow-exts M.hs > >I think you want 'ghc -c -fglasgow-exts M.hs' here. Or maybe 'ghc >-fglasgow-exts main.c M.hs' to do compilation and linking in one go. > > > /usr/lib/ghc-5.04/libHSrts.a(Main.o): In function `main': > > Main.o(.text+0x4): undefined reference to `__stginit_Main' > > Main.o(.text+0x1b): undefined reference to `Main_zdmain_closure' > > collect2: ld returned 1 exit status > > [Jacob@localhost ffi]$ ghc -fglasgow-exts main.c M_stub.c > > In file included from main.c:4: > > /usr/lib/ghc-5.04/include/RtsAPI.h:125: syntax error before `const' > > /usr/lib/ghc-5.04/include/RtsAPI.h:126: syntax error before `const' > >This is a bug in 5.04; #include "Rts.h" before RtsAPI.h to work around >it. > >Cheers, > Simon I finally got everything working, thanks for your help. Including Rts.h before RtsAPI.h in main.c was the main problem. Also i needed to include the Foo.o in addition to Foo_stub.o when I did the final linking. For example... ghc -fffi -c Foo.hs ghc -fffi Foo.o Foo_stub.o main.c .. and once again, life is good. Jacob Colvin _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx

1 0

RE: ffi howto
by Simon Marlow 30 Jul '02

30 Jul '02

> If someone could post an example of a "hs" and a "c" file and > how to compile > it with ghc, i would be very apreciative. I have looked at > > http://www.haskell.org/ghc/docs/latest/html/users_guide/sec-ff > i-ghc.html > > for a long time, and I can't figure out how to reproduce the > example. I > have noticed that if you name your hs file "M.hs" as the page > says, then ghc > will produce M_stub.h instead of the included "foo_stub.h" > that the c main > program lists. I've used windowsXP and ghc[rpm] installed on > redhat7.3, and > still nothing works. The stub files are named after the original .hs file, so if you have Foo.hs you'll get Foo_stub.c. Most people name their files after the module name, so for example Foo.hs contains module 'Foo' (in fact this is necessary if you want to use ghc --make or GHCi). > my best linux output... > [Jacob@localhost ffi]$ ls > main.c M.hs > [Jacob@localhost ffi]$ ghc -fglasgow-exts M.hs I think you want 'ghc -c -fglasgow-exts M.hs' here. Or maybe 'ghc -fglasgow-exts main.c M.hs' to do compilation and linking in one go. > /usr/lib/ghc-5.04/libHSrts.a(Main.o): In function `main': > Main.o(.text+0x4): undefined reference to `__stginit_Main' > Main.o(.text+0x1b): undefined reference to `Main_zdmain_closure' > collect2: ld returned 1 exit status > [Jacob@localhost ffi]$ ghc -fglasgow-exts main.c M_stub.c > In file included from main.c:4: > /usr/lib/ghc-5.04/include/RtsAPI.h:125: syntax error before `const' > /usr/lib/ghc-5.04/include/RtsAPI.h:126: syntax error before `const' This is a bug in 5.04; #include "Rts.h" before RtsAPI.h to work around it. Cheers, Simon

1 0

ffi howto
by jacob colvin 30 Jul '02

30 Jul '02

Hi, I've been trying to get FFI to just do something, anything, for the past few weeks and have not been able to do anything. I've looked around for documentation and have read the ghc's documention page for ffi several times and nothing works. Main problem, I think, is that I am not sure how I should compile the *.hs and *.c files. If someone could post an example of a "hs" and a "c" file and how to compile it with ghc, i would be very apreciative. I have looked at http://www.haskell.org/ghc/docs/latest/html/users_guide/sec-ffi-ghc.html for a long time, and I can't figure out how to reproduce the example. I have noticed that if you name your hs file "M.hs" as the page says, then ghc will produce M_stub.h instead of the included "foo_stub.h" that the c main program lists. I've used windowsXP and ghc[rpm] installed on redhat7.3, and still nothing works. my best linux output... [Jacob@localhost ffi]$ ls main.c M.hs [Jacob@localhost ffi]$ ghc -fglasgow-exts M.hs /usr/lib/ghc-5.04/libHSrts.a(Main.o): In function `main': Main.o(.text+0x4): undefined reference to `__stginit_Main' Main.o(.text+0x1b): undefined reference to `Main_zdmain_closure' collect2: ld returned 1 exit status [Jacob@localhost ffi]$ ghc -fglasgow-exts main.c M_stub.c In file included from main.c:4: /usr/lib/ghc-5.04/include/RtsAPI.h:125: syntax error before `const' /usr/lib/ghc-5.04/include/RtsAPI.h:126: syntax error before `const' main.c: In function `main': main.c:12: `__stginit_foo' undeclared (first use in this function) main.c:12: (Each undeclared identifier is reported only once main.c:12: for each function it appears in.) main.c: At top level: /usr/lib/ghc-5.04/include/RtsAPI.h:125: storage size of `GHCziTopHandler_runIO_closure' isn't known /usr/lib/ghc-5.04/include/RtsAPI.h:126: storage size of `GHCziTopHandler_runNonIO_closure' isn't known [Jacob@localhost ffi]$ ls Foo.hi main.c M.hs M.o M_stub.c M_stub.h M_stub.o [Jacob@localhost ffi]$ Not sure if this is the apropriate mailinglists, but I have looked in most of the others, and FFI is rarely discussed. Thank you for listening, Jacob Colvin _________________________________________________________________ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com

1 0

More on Ptr types
by George Russell 22 Jul '02

22 Jul '02

By the way, you lot are aware that under the old ANSI C standard at least, pointer types can have different sizes depending on the type? Thus a pointer to a properly-aligned 64-bit entity needs 3 less bits than one to an 8-bit entity, and implementations are entitled to use this. The only guarantee I can remember is that (void *) is big enough to represent everything. Does this affect things at all?

4 7

Re: nullPtr and NULL
by Sven Panne 17 Jul '02

17 Jul '02

Ian Lynagh wrote: > The specification of nullPtr looks to me like it is not necessarily > the same as NULL in C. Is this intentional? I don't think so: 0 resp. NULL is the only "special" pointer value in C/C++ IIRC, so this should be clarified => Manuel? Cheers, S. -- Sven Panne Fon: +49/89/99567000 Fax: +49/89/99567461 BetaResearch GmbH, Betastr. 1, D-85774 Unterfoehring mailto:Sven_Panne@BetaResearch.de http://www.betaresearch.de

2 1

nullPtr and NULL
by Ian Lynagh 16 Jul '02

16 Jul '02

The specification of nullPtr looks to me like it is not necessarily the same as NULL in C. Is this intentional? Thanks Ian

1 0

RE: Generating Function Prototypes
by Simon Marlow 08 Jul '02

08 Jul '02

> Here is nhc98's approach to solving the problem. The usual > case is for > the Haskell compiler to generate a C prototype for the FFI function > based solely on the Haskell type. On the rare occasions where the > generated prototype conflicts with a #include'd prototype, you can > add the 'noproto' modifier to the Haskell FFI decl, and the prototype > is omitted. This is both easy, and (I would guess) very portable. But surely that would be non-portable because different Haskell systems would have different prototypes in scope? Or am I not understanding the idea? Cheers, Simon

2 1

RE: Generating Function Prototypes
by Simon Marlow 08 Jul '02

08 Jul '02

> I think this is a very misleading way to describe the problem. > A major goal of the ffi is to provide a portable way of interfacing > Haskell to C. If we regard the header file as an optional extra which > some compilers need and some don't, then we have failed in that goal. > The effort of producing a header file is sufficient that ffi code > supplied without them will be very hard to port to ghc -fvia-C (and, > as I understand it, -fvia-C is considered the more stable platform > especially when doing ffi work). Sure, it's a problem, a bug in GHC, whatever. But I don't see a way around it! We can't just generate prototypes because they might conflict with prototypes already in scope. Trying to guarantee that there are *no* prototypes in scope seems too fragile - I can't imagine requiring that everything in ghc/includes must not #include any system headers or declare prototypes for anything outside the RTS. Note that in most cases you already *have* a header file because you're writing a binding for an existing C library, so the act of producing a header file isn't that much of a chore. Also you do get a small amount of typechecking this way, whereas if we were somehow able to generate prototypes then there would be no type checking at all. Cheers, Simon

3 3

RE: Generating Function Prototypes
by Simon Marlow 08 Jul '02

08 Jul '02

> >Sure, it's a problem, a bug in GHC, whatever. But I don't see a way > >around it! We can't just generate prototypes because they might > >conflict with prototypes already in scope. > > I see the problem now. > > This seems to compile (with a warning): > > typedef long long HsInt64; > > int foo (int); // annoying decl we want to ignore > > // foo :: Int64 -> IO Int64 > inline HsInt64 call_foo (HsInt64 x) > { > static HsInt64 foo(HsInt64); > return foo(x); > }; > > I haven't actually tested it, but it may be a solution. Strange; gcc doesn't generate an error for the local prototype for foo(), although it does if you remove the 'static'. My copy of the C99 standard has this to say: [#7] If, within a translation unit, the same identifier appears with both internal and external linkage, the behavior is undefined. and 20)A function declaration can contain the storage-class specifier static only if it is at file scope; see 6.7.1. which I think means that you shouldn't do this. GCC seems to be not complying with C99 here. Cheers, Simon

1 0