-----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 [EMAIL PROTECTED] -----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----- _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
