Library archives

Alastair Reid reid at
Wed Jun 19 10:35:01 EDT 2002

[Added Malcolm to list to be sure he gets this]

With the GHC folk saying they ignore lib specs, the NHC docs saying
they ignore lib specs (first bullet in and Hugs currently
treating the lib-spec as arguments to be added to the CC command line
but keen to change to something sane, I propose that we drop lib specs
from the ccall part of the ffi specification.

This will eliminate a potential source of non-portability and will
avoid the issue of global vs. local namespaces that I raised the other
day.  (Namespaces aren't an issue because, with no way of specifying
which namespace a foreign import comes from, it can only come from the
global namespace.)

How the libspec is specified is outwith the scope of the report but
it's worth describing to be sure that all implementations present and
future have a viable way of implementing it.

The way Hugs' ffi works is that you run Hugs in generate mode to
produce a .so file containing the wrappers for invoking C functions,
then you quit and you run Hugs in normal mode.  What I propose to do
for Hugs (might be useful for GHCi too?) is that when you run Hugs in
'generate ffi mode' (i.e., specify the +G flag) you can also specify a
list of .{o,a,so,obj,dll} files which are alleged to contain relevant
definitions.  These will be stored in the file generated by Hugs.
When you run Hugs in normal mode and it loads a prebuilt .o file, it
will also dlopen any .{o,a,so,obj,dll} files mentioned in the .o file.
(There's a slight circularity there - you really ought to load the
extra files _before_ you load the Hugs-generated files that refers to
them.  This may require addition of an extra file - I'll need to see.)

No doubt GHC and NHC will continue to use package descriptions.  (Hugs
won't use them because... packages haven't been implemented for Hugs

I'm not sure what GHCi's ffi story is at the moment.  Do you have to
compile ffi files with GHC and then load them or does GHCi still do
on-the-fly marshalling?  If the latter, GHCi will need to get lists of
libraries from somewhere: command line/environment variables, package
descriptions, or some other file.

Alastair Reid

Simon Marlow <simonmar at> writes:
> 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.

More information about the FFI mailing list