Re: [Gnucap-devel] gnucap development snapshot 2009-06-11

[al davis]

On Wednesday 24 June 2009, David Fang wrote:
> > There is also a question about the use of the function
> > "dlopen" which complies with the POSIX standard, but some
> > systems do not provide compliant libraries.  I don't know
> > where the mac stands on this.
>
> The idea is to use libtool's libltdl API (e.g. lt_dlopenext)
> which provides a more consistent interface that wraps around
> the differences between various platforms.

One problem with that is that "libtool's libltdl API" is not 
standard, so this is trading one non-standard for another.

Autoconf and family seem to see portability issues in a neutral 
sense.  I do not.  There are standards, there are non-standards, 
and there are broken standards.  I think it is appropriate to 
design to standards, and if needed, patch around, with full 
acknowledgement that the patch is for a broken system.

The file "md.h" exists as a place to address portability issues.
md = machine dependency, dating back to when you could only have 
8 letters in file names.  Back then, there were several variants 
of md.h.  You pick the one for your system.  Portability is much 
less of a problem now than it was 20 years ago.

The approach I took with plugin support  on windows is based on 
this ..    The code is designed around the POSIX standard.  For 
broken systems, use md.h to provide the POSIX interface as 
wrappers around whatever is available.

Now, the point is rasied suggesting libtool as the standard.  It 
isn't installed by default on some significant systems, so this 
choice suggests the need for an alternative, going back to md.h.

I have reason to believe that dlopen (POSIX standard) is 
supported by Apple:
http://developer.apple.com/documentation/Darwin/Reference/Manpages/man3/dlopen.3.html

Therefore, I see no reason not to use dlopen as per POSIX.

I do see a minor issue with the filename extension.  As it 
stands, you specify the full file name.  I'm not sure this is 
the best way.  Open for comments.  It looks like it is in the 
category with ".exe" on executables, ".o" vs ".obj" and what 
character is used as a directory separator, so at worst it could 
be handled in the same way.