Re: gnucap development snapshot 2009-06-11

> 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/