Re: Extend libtool dll namespaces for mingw-w64

[Ralf Wildenhues]

* JonY wrote on Sat, Jan 30, 2010 at 10:47:11AM CET:
> On 1/30/2010 06:55, Ralf Wildenhues wrote:
> >
> >That would be fine with me.  But I suggest that any policy decision for
> >such a naming change should be done by those projects (MinGW-W64, MinGW,
> >or both), documented there, a flag day announced, and then libtool
> >should follow suit, not the other way round.

> I am representing MinGW-W64 and have discussed this with Kai and
> Nightstrike on IRC.

We are misunderstanding each other.  I don't want Libtool to commit to
an incompatible change to library creation policy on some system due to
hearsay about a conversation on IRC, from someone I can't tell from the
website as being official.  That is just not sane engineering practice.

You guys should get together, write documentation about this on your
web site, refer to this page, rebuild your binutils ld to automatically
search for the changed prefix when it encounters -lfoo on the command
line, and propagate that new binutils to your users.

Then, I'm looking at your patch, and only that if you are willing to
sign copyright papers; otherwise I don't want to see _any_ patches but
will have to reimplement everything based on your existing detailed
documentation on how ld and the runtime work together to create, link
against, and run programs and shared libraries.[1]

If any of the Libtool users come and complain about libtool not linking
against their old (or new) libraries after we've made the change, I want
to be able to point to your documentation site and tell them "we had no
choice, upstream had a flag day, tough luck for your proprietary
software and you expecting us to remain compatible".

> Since all these DLLs all run on Windows, we can't
> expect users to constantly fiddle with PATH to load the correct DLL, or
> copy DLLs to every directory where their executables live.

That's a non-argument.  If I understood the rest of the thread
correctly, then 64bit Windows will have no problem anyway as it skips
32bit libraries.  So all you ever need to do is have one entry in the
PATH for 64bit stuff and one for 32bit stuff.  I'd even consider
installing 64bit packages in a separate --prefix from 32bit ones to be
good packaging practice, but that may just be me.

> One of the objectives in my proposal was to avoid any changes to how
> libtool behaves with mingw.org. So any changes should be confined to
> the mingw-w64 side of it.

Sure.  I understand that you don't represent MinGW, and that you are not
interested in working to reunify mingw-w64 and mingw.

> The mingw-w64 project uses the "w64" vendor key, while the normal
> distribution can use any vendor key. So it is a matter of checking for
> "w64" in the vendor key, in addition to any -m32 or -m64 arguments.

OK thanks.

Cheers,
Ralf

[1] My ld.info contains, speaking about cygwin,

     For instance, when ld is called with the argument `-lxxx' it will
     attempt to find, in the first directory of its search path,

          libxxx.dll.a
          xxx.dll.a
          libxxx.a
          xxx.lib
          cygxxx.dll (*)
          libxxx.dll
          xxx.dll

     before moving on to the next directory in the search path.

     (*) Actually, this is not `cygxxx.dll' but in fact is
     `<prefix>xxx.dll', where `<prefix>' is set by the `ld' option
     `--dll-search-prefix=<prefix>'. In the case of cygwin, the
     standard gcc spec file includes `--dll-search-prefix=cyg', so in
     effect we actually search for `cygxxx.dll'.