reid at cs.utah.edu
Tue Jun 18 13:27:00 EDT 2002
>> The questions that come up as I implement the ffi are mostly things
>> that are not clear from the spec. This is a particularily good
>> example of that - there's no example and the explanation is brief
>> and open to many interpretations. I could hunt through the
>> archives and guess at what the final decision was or I could ask
>> for clarification so that we all agree on what change is needed to
>> the report (or I look foolish when the appropriate section of the
>> report is pointed out to me).
>> In this case, all I could find was a brief discussion with no final
>> conclusion. (Or maybe I missed the conclusion - the subject lines
>> one the messages are fairly uninformative so I skimmed old mail
>> fairly quickly.)
> See these threads, for example:
I see a lot of discussion about header files.
I see a small amount of discussion of libraries with many conflicting
I see no _conclusion_.
The only conclusion is the ffi spec itself but it doesn't answer my
questions. These are:
1) What is the form of a lib spec?
A single library? Search paths? Omit/include file suffixes (.dll, .o
2) Is the library spec the only way of providing this information or
can it also be supplied externally (e.g., on the compiler command
line). The spec doesn't have to say what this way would be but it
does have to say whether it exists and, I think, what can and cannot
be overruled/added by this external spec.
And if the answer to (2) is that there are other ways (which is what
GHC has implemented), there's the important question of what if
anything is special about lib specs, when would you use one way and
not the other. That is:
3) What are library specs for?
The only hints I got from the email archive are:
1) It might save one from calling dlsym on every namespace previously
loaded. It is not clear that this is an issue though if you accept my
argument from yesterday that to make C behave correctly (and also to
keep static and dynamic linkers consistent with each other) you should
use a single namespace (i.e., specify RTLD_GLOBAL when calling
2) It is useful for .net - though I didn't hear why this was supposed
to be relevant to people calling C.
I'd like answers to these questions that are clear enough that we can
agree on them and amend the spec to be clear.
Alastair Reid reid at cs.utah.edu http://www.cs.utah.edu/~reid/
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
More information about the FFI