gnucap-devel
[Top][All Lists]

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

 From: David Fang Subject: Re: [Gnucap-devel] gnucap development snapshot 2009-06-11 Date: Thu, 25 Jun 2009 03:23:12 -0400 (EDT)

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.



I wouldn't call libtool standard, just something that makes up for deficiencies in implementations that fall short of the standard.


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.


And there are old forgotten standards and new ones.


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.



Please forgive me for incessantly defending the autotools, but I think there is a misunderstanding afoot. :) A common misunderstanding of the autotools is that they impose a burden on the users to have them installed when that is in fact quite the contrary. Autoconf generates a plain Bourne-shell script 'configure' that is distributed. Automake generates boilerplate configurable Makefiles, usable by many make variants. Likewise, the point of libtool is to not require users to have libtool installed, it works perfectly well as a distributed subpackage of your own package (FYI, this is called the "convenience" use of libltdl) and the end-user who performs configure && make need not be aware of how it works, and the configured libtool script is just another Bourne-shell script. The onus falls to the developers and maintainers (us) to apply it and distribute it along with the primary package. \emph{Bottom line: the USER need not have ANY of the autotools installed to use an autotoolized package including libtool.} This is the philosophy that distinguishes it from other build systems (cmake, scons, etc...). This philosophy shifts some responsibility to the developers and away from the users, which is why it can take some convincing for developers to adopt. :D


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.


At least, not for Darwin-7,8,9...


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.



I might've explained in the patch thread, but lt_dlopenext() only ever requires the basename of the plug-in, which is one good reason to use it over dlopen().

Have you had any success with that latest patch I sent, Al?

Fang

David Fang
http://www.csl.cornell.edu/~fang/
http://www.achronix.com/