Mail Archives: cygwin/2000/09/03/12:31:32
On Sun, Sep 03, 2000 at 01:27:12PM +0100, Gary V. Vaughan wrote:
>On Sat, Sep 02, 2000 at 10:19:15PM -0400, Chris Faylor wrote:
>> On Sat, Sep 02, 2000 at 11:19:25PM +0100, Gary V. Vaughan wrote:
>> >> Since windows-dll
>> >> loading is based on the executable path, and not 'LD_LIBRARY_PATH' or
>> >> similar, you've got a problem.
>> >
>> >Most definitely.
>>
>> It is *not* strictly based on the executable path. It first searches
>> the current directory, then searches the directory containing the executable.
>> Most Windows packages rely on this and place the DLL with the executable.
>> That should solve the problem of finding the "wrong" dll.
>>
>> I'm still kind of amazed by all of the furor this discussion is generating,
>> given that I don't think we have yet seen a single problem reported.
>>
>> If this was a big deal I would have thought that there would be many many
>> plaintive wails in this mailing list.
>>
>> If the solution to the problem is as simple as placing the DLL with the
>> executable then why the heck don't we just do that? I love being as
>> close to UNIX as possible but if it is going to cause problems then
>> it makes sense not to do things that way.
>
><rant>
>Why not just statically link all of our applications? Then we
>wouldn't have any problems with wrong dlls being loaded at all!
>
>Everyone agrees that shared libraries on Unix are a good idea, right?
>How come so many of us think that the best way to use shared libraries
>on Windows is to make them as much like static libraries as we can?
>The closest thing to a static library *is* a static library. Lets get
>off the fence here. If we want static libraries then fine, I'll shut
>up and go away. If we want shared libraries, wouldn't it be cool to
>hammer out the easiest (from a man-hours effort point of view) way to
>take advantage of the benefits they can offer?
>
>The whole point of a shared library, is that it is shared by the
>applications that use it. You can upgrade all of the applications
>that use it by updating the shared library. You only need to have one
>copy in memory.
>
>Putting a copy of all the dll's used by each application into the
>directory the application loads from defeats the purpose. I know dll's
>are sucky compared to ELF shared libraries, and that the windows
>runtime loader is sucky compared to ld.so. But wouldn't it be nice to
>have some of the advantages shared libraries bring to Unix when we use
>cygwin? I'm even offering to do most of the work by making all the
>libtool using packages (i.e. just about everything from gnu.org and a
>whole buch of other stuff too) conform to whatever scheme we agree
>will work the best. I'll bet that if we converted the non-libtool
>packages that we port to an autoconf/automake/libtool build system,
>the upstream maintainers would incorporate the patch into the real
>version, and the next release would work on cygwin out of the box.
>Assuming we choose a good scheme for libtool built dlls on cygwin.
></rant>
Are you ranting at me? Don't bother.
Chuck Wilson has adequately explained why "just put the DLL in
the same directory" isn't a perfect plan.
Regardless, I wasn't advocating putting each executable in its own
directory with a DLL.
My major concern was naming every cygwin DLL "cygsomething.dll". I
really don't like that idea, especially since it will mean work for
people at Red Hat to accomodate.
If you have a plan that doesn't require changing the name of libz.dll to
something like cyglibz.dll then I have no objections.
I did see the AppPath registry key being mentioned. I'm not sure how
libtool could make use of that since that is something that is set on
installation of a package. libtool may be out of the picture at that
point unless you're doing 'make install'.
I think it may be possible to have a dll that is loaded before most
other dlls change the PATH so that something like /usr/lib is first in
the path, removing the /usr/lib prior to execution of 'main()'. We
could, in fact, even add a front end to kernel32.dll which did this.
This could be a solution for cygwin but I don't know if it addresses the
problem of other packages or not.
cgf
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -