[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cygwin convenience library -dlpreopen installation
From: |
Ralf Wildenhues |
Subject: |
Re: cygwin convenience library -dlpreopen installation |
Date: |
Sun, 10 Sep 2006 14:48:02 +0200 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
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