Manuel M. T. Chakravarty
chak at cse.unsw.edu.au
Sun Jun 16 06:37:18 EDT 2002
Alastair Reid <reid at cs.utah.edu> wrote,
> The current spec contains no examples of how you would specify a
> library archive. Which of the following are legal:
> foreign import ccall "[Storable_cbits.o]" readCharOffPtr :: ...
> foreign import ccall "[libc.so]" malloc :: ...
> foreign import ccall "[libc.a]" malloc :: ...
> foreign import ccall "[-lc]" malloc :: ...
> foreign import ccall "[-L/usr/lib -lc]" malloc :: ...
> I'm assuming that any relative filenames should be interpreted as being
> relative to the directory containing the .hs file.
> My current interpretation is that anything legal on a link line is ok
> (so all the above are kosher) but it may be sensible to limit it to
> just the first 3 forms.
> I'd like the spec to say what's legal and give at least one example.
The actual motivation for inclusion of the library
specification was that SPJ pointed out that it would
otherwise be difficult to generate code for .NET (where
apparently you need to give the name of the dll or so when
calling a non-.NET function in the IL). In that case, it'll
probably be something like
foreign import ccall "[libc]" malloc :: ...
Without this requirement for .NET, we would have omitted the
library specification altogether as something which is much
too system dependent. Hence, personally, I would tend to
restrict the string in square brackets to the name of a
library without a suffix. The suffix and other link options
would, then, need to be supplied by the Haskell system or
via command line options to the compiler and/or linker. I
favour this, as it seems to be the most likely scenario that
makes a single foreign import declaration work on more than
one platform. (I would also give the Haskell system the
option of ignoring the library spec altogether.)
I am not sure what others think about this.
More information about the FFI