RE: Some fixes for cygwin

[Robert Collins]

> -----Original Message-----
> From: Bob Friesenhahn [mailto:address@hidden 
> Sent: Monday, 3 June 2002 12:15 PM
> To: Robert Collins
> Cc: 'Charles Wilson'; 'Gary V. Vaughan'; address@hidden
> Subject: RE: Some fixes for cygwin
> 
> 
> On Mon, 3 Jun 2002, Robert Collins wrote:
> > > Perhaps.  But that would need to be transparent to the user AND
> > > developer: we don't want to force Joe Developer to change 
> his code to
> > > explicitly dlpreopen the modules...so it would have to be
> > > some sort of
> > > constructor thing...
> >
> > Exactly. The dlpreopen capability is transparent, the user 
> thinks they
> > are using dlopen... even when statically linked. I'll need 
> to check the
> 
> Not all packages that use libltdl use the dlpreopen capability.  For
> example, ImageMagick removes libltdl from the picture if it is built
> statically.  There is more than one way to skin a cat.

Agreed. And in such situations the code path would never get hit (as it
would be part of libltdl's import library), so if you don't link against
libltdl, there is no impact at all.
 
> > it would be 100% transparent. Gcc has an attribute for 
> functions that
> > makes them a constructor, they get called before main() :}.
> 
> Gcc is one compiler among many.  Please don't assume that only gcc
> will be used.

We are talking about compilers currently supported by libtool targeting
the cygwin platform. There are... Let me see. Oh, yes. 1. That's right,
one compiler for the cygwin platform. As soon as another compiler
targets cygwin, then this does become a discussion point.

Rob