Re: Extend libtool dll namespaces for mingw-w64

[Dave Korn]

On 29/01/2010 01:10, JonY wrote:
> On 1/29/2010 04:07, Ralf Wildenhues wrote:

> Yes, GCC trunk uses that, but right now, -bindir for both 32bit and
> 64bit subsystems point to the same dir.
> 
> Another solution it to stop installing DLLs to bindir and follow unix
> style installs into libdir, right beside the import libs, let the user
> set the PATH. That way, we don't need a bin32 and bin64 directory, but
> it does not prevent possible conflicts with 32bit mingw-w64 and
> mingw.org DLLs.

  This is GCC PR40125, and I don't suppose I'm going to be able to fix it
before 4.5.0.  Kai suggested we should leave them in gcc's private dir (which
is where the language runtime import libs go, not libdir), but libdir is as
good as any.

  I think that in all the focus on bitness, and whether or not it is necessary
to separate 32-vs-64, has distracted from the very different issue of how we
keep 32-bit MinGW DLLs from clashing with 32-bit MinGW-W64 DLLs.  That is a
situation *exactly* analagous to the Cygwin-vs-MinGW clash, and I think it
fully justifies using a separate prefix.  Although at some time in the future
there may be a reunification between MinGW and MinGW-W64, at the moment they
are effectively separate ABIs, and although it would probably "mostly work" to
try interchanging them, we shouldn't.

  It's not going to be possible to educate the entire Windows-using fraternity
into keeping tight control over their PATH settings.  It's not how they work,
and it's not how Windows encourages them to work.  Windows users generally set
their PATH through their GUI control panel and aren't in the habit of varying
it on per-application basis.  That's why we had to keep Cygwin DLLs and MinGW
in a separate namespace; people simply _are_ going to have both in their PATH
at the same time, and we just have to deal.  (Windows doesn't help here by
implicitly placing "." at the front of your PATH for dll-search purposes
either, and nor do we have a runpath to get us out of trouble; DLLs are
searched by basename only.)

  So I think what I'd conclude is that MinGW-W64 should have its own prefix,
but it should be the same one for 32-bit and 64-bit W64 DLLs.

    cheers,
      DaveK