Library archives

[Alastair Reid]

Alastair:
>> 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.)

Simon:
> See these threads, for example:

> 	http://www.haskell.org/pipermail/ffi/2001-February/000212.html
>       http://www.haskell.org/pipermail/ffi/2001-May/000345.html

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_.

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
   etc.)

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
   dlopen).

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
   behaviour.