Re: cygwin convenience library -dlpreopen installation

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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,
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; but with the -static flag, gcc will pick up the
static library, the .exe is bigger, but there is no .dll dependence.  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 (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).

> 
> Unless Somebody intended -dlpreopen to be completely different from
> what the documentation says; then they should speak up and fix the
> documentation.
> 
> 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.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFAtwq84KuGfSFAYARAuumAJwNv6j3Xov2UcK3RNtq5LQ5opQ+KACdET4k
otCe1WCccAOtZU4GxLmTu2M=
=lAFy
-----END PGP SIGNATURE-----