Mail Archives: cygwin/2000/09/03/08:32:14
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>
Cheers,
Grumpy^H^H^H^H^H^HGary =)O|
--
___ _ ___ __ _ mailto: gvv AT techie DOT com
/ __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ gary AT gnu DOT org
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
\___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page: /___/ /___/ gpg public key:
http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -