Re: cygwin convenience library -dlpreopen installation

[Ralf Wildenhues]

Hello Eric,

* Eric Blake wrote on Sat, Sep 09, 2006 at 05:22:18PM CEST:
> According to Ralf Wildenhues on 9/9/2006 12:30 AM:
> >>> That is what -dlpreopen is documented to do.  -dlopen should use the
> >>> static versions only when shared libs are not available, e.g., due to
> >>> --disable-shared or some other reason.
> >> Then perhaps the right fix is making -dlpreopen on Windows be a key that
> >> the convenience library .dll must be installed alongside the final image
> >> in PATH.
> > 
> > No.  It should not link against the dll at all.  It should use the
> > static archive.  Problem with paths solved (for this case).
> 
> I'm not familiar enough with libtool to know where to tackle this problem,

I intend to tackle it eventually (when I have enough time at one time).

> but I do know that by default, when both libfoo.a and libfoo.dll.a exist
> in the library search path (ie. the library was compiled both static and
> shared), gcc will pick up the dynamic library and hard code the .dll
> dependence into the .exe;

That is with
  gcc -o output -lfoo

right?

> but with the -static flag, gcc will pick up the
> static library, the .exe is bigger, but there is no .dll dependence.

Sure.  What about
  gcc -o output /path/to/libfoo.a

or
  gcc -o output -L/path/to libfoo.a

(and what happens if I  s/libfoo\.a/libfoo.dll.a/  in these cases)?

> I also don't know if -static operates on a per-library basis, but it
> seems like we would have to figure that out, so that only the
> -dlpreopen'd libraries are statically linked

If listing the library as above works, we don't need to worry about this
(yet).

> (back to the m4 example, we want the convenience library traditional.a
> statically linked, since it is unlikely to upgrade without also
> upgrading m4.exe, but the dynamic library cygintl-8.dll dynamically
> linked, since libintl is an external library and we want to pick up
> upgrades without recompiling m4.exe).

Sure.

> > Bummer is that we may still have to think about the path issue in the
> > --disable-static case, as we may not have a static library available.
> > In that case your suggestion of linking dlls from any extra path into
> > bindir sounds like an idea -- ugly as hell, but that would fit just
> > right for w32.  ;->
> 
> It would have to be a hard link (on NT systems and NTFS drives, which
> breaks down to a copy on Win9x systems or FAT drives), because Windows
> does not follow cygwin symlinks when resolving .dlls.

Oh, ok, we need to take care of this too then.  Thanks.

Cheers,
Ralf