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