Re: Extend libtool dll namespaces for mingw-w64

[Roumen Petrov]

JonY wrote:

On 1/31/2010 02:14, Roumen Petrov wrote:

I don't understand request as the usually final result is
.../libfool.la
.../libfool.dll.a
.../libfool.dll
.../libfool.a

Also note that makefiles the macros(variables) are libfoo_.
Did the requester expect if target is libfoo_ make command to search
for libYYfoo_ or may be requested will contact all developers as
will convince to use macros like @libpre...@foo_ in makefiles and
LIBPREFIX is set by configure ?
Uhh ...



Hi,

If you looked at the concept patch, it changes how libtool names the
DLL by soname_spec, libname_spec stays the same. The makefiles do not
see the DLLs at all, only the .la files if libtool is in use. The .la
filenames stay the same.

That is the whole point of libtool, devs don't need to bother about
platform specific details and implementation of shared libs.



Uhh and the libtool install la files and process installed. So after 
installation xx-bit will override yy-bit.


Roumen



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[JonY]

On 2/1/2010 01:18, Roumen Petrov wrote:

JonY wrote:

On 1/31/2010 02:14, Roumen Petrov wrote:

I don't understand request as the usually final result is
.../libfool.la
.../libfool.dll.a
.../libfool.dll
.../libfool.a

Also note that makefiles the macros(variables) are libfoo_.
Did the requester expect if target is libfoo_ make command to search
for libYYfoo_ or may be requested will contact all developers as
will convince to use macros like @libpre...@foo_ in makefiles and
LIBPREFIX is set by configure ?
Uhh ...



Hi,

If you looked at the concept patch, it changes how libtool names the
DLL by soname_spec, libname_spec stays the same. The makefiles do not
see the DLLs at all, only the .la files if libtool is in use. The .la
filenames stay the same.

That is the whole point of libtool, devs don't need to bother about
platform specific details and implementation of shared libs.



Uhh and the libtool install la files and process installed. So after
installation xx-bit will override yy-bit.



GCC already does the correct install for import libs for multilib
configuration with lib32,lib64.

For other packages that are not explicitly designed with multilib in
mind, use a different --prefix.


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[JonY]

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.



Hi,

I am representing MinGW-W64 and have discussed this with Kai and
Nightstrike on IRC. 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.

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.

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.


___
http://lists.gnu.org/mailman/listinfo/libtool

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
 `prefi.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'.


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[Dave Korn]

On 30/01/2010 14:56, Ralf Wildenhues wrote:

 web site, refer to this page, rebuild your binutils ld to automatically
 search for the changed prefix when it encounters -lfoo on the command

  Not binutils, I don't think:

 [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
  `prefi.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'.


  Yes; this relies entirely on the compiler's LINK_SPEC to pass the correct
--dll-search-prefix, as far as I know; W64 team need to do the same with their
compiler specs.  It's not part of LD itself.

cheers,
  DaveK


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[JonY]

On 1/30/2010 22:56, Ralf Wildenhues wrote:


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.



I see, I will get a wiki entry to explain the change.


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.



I misunderstood one of the users who was testing an XP 64bit, it seems
that it does not skip incompatible DLLs like Vista or 7. After some
confirmation, its clear that XP64 does skip properly, so maybe having
the same prefix for 64bit/32bit mingw-w64 DLLs would work.

The --prefix thing may not work for installing multilib GCC though. GCC 
could be changed to install DLLs into lib{32,64} so it doesn't get 
clobbered on install. This fixup can come later.




___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[Ralf Wildenhues]

* JonY wrote on Sat, Jan 30, 2010 at 05:29:31PM CET:
 I misunderstood one of the users who was testing an XP 64bit, it seems
 that it does not skip incompatible DLLs like Vista or 7. After some
 confirmation, its clear that XP64 does skip properly, so maybe having
 the same prefix for 64bit/32bit mingw-w64 DLLs would work.

No, you're getting it wrong again.  If all systems you're interested in
do skip incompatible DLLs properly, then there is *absolutely* no reason
any more to rename them for bitness.  Just use different --prefix values
for your binaries, put both bindirs in PATH, and be done with it once
and for all.

Really, please do take advice from people who have struggled with
multilib on other systems.  Don't do this renaming thing for bitness,
don't try to handle different binary packages as if you could reunify
them.  You'll return next month with renaming for C++ exception
handling, and later for a different calling convention.  Argh.

 The --prefix thing may not work for installing multilib GCC though.
 GCC could be changed to install DLLs into lib{32,64} so it doesn't
 get clobbered on install. This fixup can come later.

GCC is a *special* case, to be fixed in the GCC package.  Don't confuse
the compiler+tools special cases with the rest of normal packages.

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[Roumen Petrov]

I don't understand request as the usually final result is
.../libfool.la
.../libfool.dll.a
.../libfool.dll
.../libfool.a

Also note that  makefiles the macros(variables) are libfoo_.
Did the requester expect if target is libfoo_ make command to search 
for libYYfoo_  or may be requested will contact all developers as 
will convince to use macros like @libpre...@foo_ in makefiles and 
LIBPREFIX is set by configure ?

Uhh ...

Roumen


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[Tor Lillqvist]

 That is just not sane engineering practice.

 I'd even consider
 installing 64bit packages in a separate --prefix from 32bit ones to be
 good packaging practice,

 GCC is a *special* case, to be fixed in the GCC package.  Don't confuse
 the compiler+tools special cases with the rest of normal packages.

I agree fully with Ralf on all points.

--tml


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[JonY]

On 1/31/2010 02:14, Roumen Petrov wrote:

I don't understand request as the usually final result is
.../libfool.la
.../libfool.dll.a
.../libfool.dll
.../libfool.a

Also note that makefiles the macros(variables) are libfoo_.
Did the requester expect if target is libfoo_ make command to search
for libYYfoo_ or may be requested will contact all developers as
will convince to use macros like @libpre...@foo_ in makefiles and
LIBPREFIX is set by configure ?
Uhh ...



Hi,

If you looked at the concept patch, it changes how libtool names the
DLL by soname_spec, libname_spec stays the same. The makefiles do not
see the DLLs at all, only the .la files if libtool is in use. The .la
filenames stay the same.

That is the whole point of libtool, devs don't need to bother about
platform specific details and implementation of shared libs.


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[JonY]

On 1/29/2010 10:29, Bob Friesenhahn wrote:

On Fri, 29 Jan 2010, JonY wrote:


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.


When in Rome, do what the Romans do. Windows users do not set paths.
Setting the path is hard to do under Windows. Period.

There needs to be the ability to build and execute both 32 and 64 bit
libraries and have them both in the same executable search PATH. This is
a fundamental requirement.



Hi,

I agree with your statement, that is why I proposed on extending the
namespace for Windows based targets, so everything can still be in
PATH, without trying to kill each other.


___
http://lists.gnu.org/mailman/listinfo/libtool

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



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[JonY]

On 1/29/2010 20:16, Dave Korn wrote:

   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.



Hi,

I'm not entirely sure how to avoid 64bit vs 32bit mingw-w64 clashing if 
both use the same DLL naming scheme.


Anyway, enough talk, attached is a very crude but working conceptual
patch that makes mingw-w64 prefix distinct from mingw.org. It could
really do better.

It currently does l32 for 32bit mingw-w64 and l64 for 64bit mingw-w64
(and multilib -m32/-m64 detection). It can of course be changed to use
the same prefix for w64 based targets.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 80a1ff3..45798fc 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -4215,6 +4215,28 @@ func_mode_link ()
continue
;;
 
+  -m32)
+   archive_cmds=$archive_cmds -m32
+   case $host in
+   *-w64-mingw*)
+   MULTILIB_PREFIX=l32
+   ;;
+   *) ;;
+   esac
+   continue
+   ;;
+
+  -m64)
+   archive_cmds=$archive_cmds -m64
+   case $host in
+   *-w64-mingw*)
+   MULTILIB_PREFIX=l64
+   ;;
+   *) ;;
+   esac
+   continue
+   ;;
+
   -no-undefined)
allow_undefined=no
continue
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 29f1222..f6bb69a 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2084,6 +2084,7 @@ BEGIN {RS= ; FS=/|\n;} {
 else
   sys_lib_search_path_spec=/lib /usr/lib /usr/local/lib
 fi])
+MULTILIB_PREFIX=
 library_names_spec=
 libname_spec='lib$name'
 soname_spec=
@@ -2227,6 +2228,22 @@ m4_if([$1], [],[
 mingw* | cegcc*)
   # MinGW DLLs use traditional 'lib' prefix
   soname_spec='${libname}`echo ${release} | $SED -e 
's/[[.]]/-/g'`${versuffix}${shared_ext}'
+  case $host_vendor in
+w64)
+soname_spec='`echo ${libname} | sed -e 
's/^lib/\${MULTILIB_PREFIX}/'``echo ${release} | $SED -e 
's/[[.]]/-/g'`${versuffix}${shared_ext}'
+case $host in
+x86_64-*)
+  MULTILIB_PREFIX=l64
+;;
+i?86-*)
+  MULTILIB_PREFIX=l32
+;;
+esac
+;;
+  *)
+soname_spec='${libname}`echo ${release} | $SED -e 
's/[[.]]/-/g'`${versuffix}${shared_ext}'
+  ;;
+  esac
   ;;
 pw32*)
   # pw32 DLLs use 'pw' prefix rather than 'lib'
@@ -2705,6 +2722,8 @@ _LT_DECL([], [libname_spec], [1], [Format of library name 
prefix])
 _LT_DECL([], [library_names_spec], [1],
 [[List of archive names.  First name is the real one, the rest are links.
 The last name is the one that the linker finds with -lNAME]])
+_LT_DECL([], [MULTILIB_PREFIX], [0],
+[MULTILIB PREFIX STRING])
 _LT_DECL([], [soname_spec], [1],
 [[The coded name of the library, if different from the real name]])
 _LT_DECL([], [install_override_mode], [1],
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[Ralf Wildenhues]

Hi Dave,

thanks for the feedback.

* Dave Korn wrote on Fri, Jan 29, 2010 at 01:16:37PM CET:
   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.
[...]
   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.

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.

Or maybe, just maybe, they'll re-merge before it gets that far ...

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[JonY]

On 1/28/2010 13:46, Ralf Wildenhues wrote:

* JonY wrote on Tue, Jan 26, 2010 at 04:26:32PM CET:

Currently, on Win32 platforms, Cygwin uses the cyg prefix for dlls,
and MinGW based systems uses the lib prefix.

This works fine, until mingw-w64 showed up with 64bit dlls. This
problem is especially apparent with trying to build mingw-w64 cross
compilers.

For example, both mingw and mingw-w64 builds libstdc++-6.dll from GCC.
When installed, there might be up to 3 incompatible versions of
libstdc++-6.dll, from mingw.org, 32bit mingw-w64 and 64bit mingw-w64.


MinGW and MinGW64 should cooperate on issues like this.  Libtool has
little to no bearing here, except to follow.  Libtool cannot decide what
the runtime system will load.



Hi

My proposal has the same rationale as using the cyg and lib prefix
on Cygwin and MinGW, so no DLLs can clash. The issue is that libtool
uses the lib prefix for both 64bit and 32bit DLLs, and for both mingw
and mingw-w64.


I suggest the following naming scheme.


I suggest we follow whatever naming scheme Windows uses.  Including none
if none.  GNU libtool certainly shouldn't choose its own flavor.



This has nothing to do with Windows naming schemes, DLLs can be named
anything, including with a .so extension. This has to do with libtool
DLL naming schemes. I'm working to prevent DLLs from overwriting each
other, especially on install for multilib gcc.

Are you suggesting that DLLs are to be installed to /lib32 and /lib64
instead of bindir? That way, DLLs won't clash, to a certain extent.


libtool should also check if GCC -m32 or -m64 is used, and select
the proper namespace accordingly (mingw-w64 GCC can do multilib).


No, the developer should have her $PATH set correctly.



PATH is irrelevant when DLLs with the same name overwrite each other on
mulitlib GCC installs, so you end up with a copy of whatever that was
last installed.


What does the Windows kernel do if it finds a needed shared library of
the wrong ABI early in $PATH while trying to start a program?  Fail or
skip, and if skip, silently or verbosely?



It may skip paths when encountering DLLs of the wrong bitness on Win64,
not so on Win32, where it fails automatically when encountering 64bit
versions of 32bit DLLs with the same name. mingw.org DLLs having the
same name with 32bit mingw-w64, making things even more complicatd,
both are 32bit, but compatibilities not guaranteed, especially with
SJLJ vs DW2 libstdc++-6.dll.


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[Tor Lillqvist]

 The issue is that libtool
 uses the lib prefix for both 64bit and 32bit DLLs, and for both mingw
 and mingw-w64.

Well, my take is that except for people working on the *tools
themselves* (meaning gcc, binutils etc), this is not really a problem.
Sure, libtool is a tool used by developers, but the end result, DLLs,
are intended to be used by end-users running applications.

I see two cases. 1) On 32-bit Windows, no end-user should in a normal
scenario be having 64-bit binaries anyway. (End-users use installers,
which surely should check whether the OS is a 64-bit one before
installing 64-bit binaries. If somebody is unzipping some random
archive containing 64-bit DLLs onto his 32-bit system and setting up
PATH to include them, they aren't really end-users but wannabe hackers
doing stuff they really don't understand. One can't protect against
people like that.)

Case 2) On 64-bit Windows, it's fine to have in PATH two instances of
a DLL with the same name, one being 32-bit and the other 64-bit. The
runtime loader will load the correct one when some other module (exe
or dll, 32- or 64-bit) requires it.

 This has nothing to do with Windows naming schemes, DLLs can be named
 anything, including with a .so extension. This has to do with libtool
 DLL naming schemes. I'm working to prevent DLLs from overwriting each
 other, especially on install for multilib gcc.

That is then something gcc's configury should be fixed to handle.

 It may skip paths when encountering DLLs of the wrong bitness on Win64,

That is indeed my impression too. (Please, let's try to avoid using
the convenient, but wrong, term Win64. The Win32 API can be either
32- or 64-bit. Using 64-bit Windows is not that much more verbose.)

 not so on Win32, where it fails automatically when encountering 64bit
 versions of 32bit DLLs with the same name.

Yeah, but as I said above, my opinion is that such a situation with
64-bit DLLs present on a 32-bit Windows is an anomaly that in reality
occurs only on machines of *developers* working on cross-builds of the
MinGW toolchain itself, or cross-builds of other software. Such people
should just know what they are doing. And if the build mechanism of
some software incorrectly makes it so that the OS tries to use
cross-built binaries not intended for the build system, that is the
problem of the build mechanisms of the software in question. Not a
libtool problem.

=== I guess my main point is: ===

This is in no way unique to cross-building from 32-bit Windows to
64-bit Windows. You can't say from the name of an ELF shared object as
produced by libtool what architecture it is for either.

Or do you suggest that libtool should start using a platform triplet
specific prefix in *all* instances instead of just lib?

--tml


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[JonY]

On 1/28/2010 19:30, Tor Lillqvist wrote:

The issue is that libtool
uses the lib prefix for both 64bit and 32bit DLLs, and for both mingw
and mingw-w64.


Well, my take is that except for people working on the *tools
themselves* (meaning gcc, binutils etc), this is not really a problem.
Sure, libtool is a tool used by developers, but the end result, DLLs,
are intended to be used by end-users running applications.

I see two cases. 1) On 32-bit Windows, no end-user should in a normal
scenario be having 64-bit binaries anyway. (End-users use installers,
which surely should check whether the OS is a 64-bit one before
installing 64-bit binaries. If somebody is unzipping some random
archive containing 64-bit DLLs onto his 32-bit system and setting up
PATH to include them, they aren't really end-users but wannabe hackers
doing stuff they really don't understand. One can't protect against
people like that.)

Case 2) On 64-bit Windows, it's fine to have in PATH two instances of
a DLL with the same name, one being 32-bit and the other 64-bit. The
runtime loader will load the correct one when some other module (exe
or dll, 32- or 64-bit) requires it.



Hi,

With DLLs named differently, they simply can't clash, however hard you
try, idiot proof as well, no more messing with PATH.

Distributing for end-users is never a problem, as long as they don't try 
to be idiots and mix dlls with similar names for different archs.



This has nothing to do with Windows naming schemes, DLLs can be named
anything, including with a .so extension. This has to do with libtool
DLL naming schemes. I'm working to prevent DLLs from overwriting each
other, especially on install for multilib gcc.


That is then something gcc's configury should be fixed to handle.



Yes, GCC uses libtool to handle most target lib linking and installing,
which leads us back to libtool's --mode=install, or --mode=link,
depending on the fix method.

GCC make install currently installs both 32bit and 64bit dlls to the
same /bin, unless we switch to the UNIX'ish convention of installing
shared libraries to /lib{,32,64}, the problem remains because 2 dlls
installing into the same /bin.


It may skip paths when encountering DLLs of the wrong bitness on Win64,


That is indeed my impression too. (Please, let's try to avoid using
the convenient, but wrong, term Win64. The Win32 API can be either
32- or 64-bit. Using 64-bit Windows is not that much more verbose.)


not so on Win32, where it fails automatically when encountering 64bit
versions of 32bit DLLs with the same name.


Yeah, but as I said above, my opinion is that such a situation with
64-bit DLLs present on a 32-bit Windows is an anomaly that in reality
occurs only on machines of *developers* working on cross-builds of the
MinGW toolchain itself, or cross-builds of other software. Such people
should just know what they are doing. And if the build mechanism of
some software incorrectly makes it so that the OS tries to use
cross-built binaries not intended for the build system, that is the
problem of the build mechanisms of the software in question. Not a
libtool problem.



As I said earlier, you can't have the DLLs installed properly at all,
they overwrite each other on install, there is also the problem of
trying to redistribute the DLL that has been overwritten. This happens
even on Linux hosted mingw-w64 multilib toolchains.

There are currently 2 ways of solving this to allow more than 1 
toolchain on Windows:


1. Stop installing DLLs to bindir, DLLs are to be installed following 
Unix-ish conventions into libdir. This has the nice effect of moving

multilib DLLs to their respective libdirs, users will need to take care
of the PATH env themselves. However, doesn't stop 32bit mingw-w64 built
DLLs from clashing with mingw.org versions.

2. Change the DLL prefixes. This way, binaries can continue with
installing into /bin, with no possibility of clashing.


===  I guess my main point is:===

This is in no way unique to cross-building from 32-bit Windows to
64-bit Windows. You can't say from the name of an ELF shared object as
produced by libtool what architecture it is for either.

Or do you suggest that libtool should start using a platform triplet
specific prefix in *all* instances instead of just lib?



There is no problem with Linux .so files, the Linux dynamic library
loader handles this problem gracefully because .so files live in
libdir (lib{,32,64} respectively).

Windows DLLs OTOH are installed always to bindir, unlike Linux .so 
files, so they clash.


Cygwin's way of working around this is to use the cyg prefix for
Cygwin DLLs, so provided mingw.org versions of libraries do not clash
with Cygwin versions.

I am extending this idea for mingw-w64, I can't see why we can't use the
l32/l64name namespace, incompatible DLLs should have different names.
The lib prefix is already used by mingw.org.

Yes, having the platform triplet in the DLL name is fine too, as long as 
it does not clash with 

Re: Extend libtool dll namespaces for mingw-w64

[Ralf Wildenhues]

[ Dave, this is
  http://thread.gmane.org/gmane.comp.gnu.libtool.general/10723;
  see at the end for a quick GCC-related question ]

Hello,

first off, I completely agree with Tor's reply to your message.
Adding a couple of bits:

* JonY wrote on Thu, Jan 28, 2010 at 11:06:50AM CET:
 On 1/28/2010 13:46, Ralf Wildenhues wrote:
 * JonY wrote on Tue, Jan 26, 2010 at 04:26:32PM CET:
 Currently, on Win32 platforms, Cygwin uses the cyg prefix for dlls,
 and MinGW based systems uses the lib prefix.
 
 This works fine, until mingw-w64 showed up with 64bit dlls. This
 problem is especially apparent with trying to build mingw-w64 cross
 compilers.
[...]
 MinGW and MinGW64 should cooperate on issues like this.  Libtool has
 little to no bearing here, except to follow.  Libtool cannot decide what
 the runtime system will load.

 My proposal has the same rationale as using the cyg and lib prefix
 on Cygwin and MinGW, so no DLLs can clash.

No, that is not the same thing.  The Cygwin runtime system actually
looks for libraries named cygNAME.dll; see 'info ld WIN32'.  The
GNU libc runtime linker has builtin functionality to look for different
variants and ABIs of a certain library, to do multi-ABI on x86_64 and
elsewhere.  None of this maps to the issue at hand.

I suggest that a very practical solution is to simply keep 32bit and
64bit executables in different $(bindir) directories.  The current git
Libtool allows you to specify the -bindir in which the DLLs are supposed
to end up.  I know that svn trunk of GCC uses that, but I'm not sure if
it is used to put 32bit DLLs in another place than 64bit ones.  It might
be good to check that before the 4.5 release.  (CC:ing Dave).

 The issue is that libtool
 uses the lib prefix for both 64bit and 32bit DLLs, and for both mingw
 and mingw-w64.

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[JonY]

On 1/29/2010 04:07, Ralf Wildenhues wrote:

My proposal has the same rationale as using the cyg and lib prefix
on Cygwin and MinGW, so no DLLs can clash.


No, that is not the same thing.  The Cygwin runtime system actually
looks for libraries named cygNAME.dll; see 'info ld WIN32'.  The
GNU libc runtime linker has builtin functionality to look for different
variants and ABIs of a certain library, to do multi-ABI on x86_64 and
elsewhere.  None of this maps to the issue at hand.



Hi,

this has nothing to do with the libc runtime linker, this has to do with 
preventing possible DLL conflicts on Windows for DLLs with potential ABI 
difference.


I get No menu item `win32' in node `(ld.info)Top'. for info ld WIN32.
Do you mean --dll-search-prefix? If so it can be easily extended as
well.

ld doesn't really have anything to do with runtime DLL resolving. The 
import lib determines what DLL names the executables will look for.



I suggest that a very practical solution is to simply keep 32bit and
64bit executables in different $(bindir) directories.  The current git
Libtool allows you to specify the -bindir in which the DLLs are supposed
to end up.  I know that svn trunk of GCC uses that, but I'm not sure if
it is used to put 32bit DLLs in another place than 64bit ones.  It might
be good to check that before the 4.5 release.  (CC:ing Dave).



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.


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[Bob Friesenhahn]

On Fri, 29 Jan 2010, JonY wrote:


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.


When in Rome, do what the Romans do.  Windows users do not set paths. 
Setting the path is hard to do under Windows.  Period.


There needs to be the ability to build and execute both 32 and 64 bit 
libraries and have them both in the same executable search PATH. 
This is a fundamental requirement.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[Peter Rosin]

Den 2010-01-26 16:26 skrev JonY:

I suggest the following naming scheme.

mingw.org:libname-major.dll (unchanged)
Cygwin:cygname-major.dll (unchanged)
mingw-w64(64):lib64name-major.dll
mingw-w64(32):lib32name-major.dll


But then mingw-w64 invades the mingw.org namespace. Perhaps
l64name-major.dll and l32name-major.dll?

Cheers,
Peter

--
They are in the crowd with the answer before the question.
 Why do you dislike Jeopardy?


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[JonY]

On 1/27/2010 18:02, Peter Rosin wrote:

Den 2010-01-26 16:26 skrev JonY:

I suggest the following naming scheme.

mingw.org: libname-major.dll (unchanged)
Cygwin: cygname-major.dll (unchanged)
mingw-w64(64): lib64name-major.dll
mingw-w64(32): lib32name-major.dll


But then mingw-w64 invades the mingw.org namespace. Perhaps
l64name-major.dll and l32name-major.dll?

Cheers,
Peter



Hi,

this is better than libbitness. So, any ideas where to begin
implementing this?


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[Matěj Týč]

On Tue, 2010-01-26 at 23:26 +0800, JonY wrote:
...
 I suggest the following naming scheme.
 
 mingw.org:libname-major.dll (unchanged)
 Cygwin:   cygname-major.dll (unchanged)
 mingw-w64(64):lib64name-major.dll
 mingw-w64(32):lib32name-major.dll
 
 libtool should also check if GCC -m32 or -m64 is used, and select
 the proper namespace accordingly (mingw-w64 GCC can do multilib).
 
 Comments?
 

AFAIK if you use automake, you have to have something like the following
line in Makefile.am:
lib_LTLIBRARIES = libfoo.la
This means that the 'lib' prefix doesn't actually come from mingw, but
from your automake setup, right?

In order to be able to change the library name in a smarter way,
something like
lib_LTLIBRARIES = @lib...@foo.la # LIBrary PREfix
would be needed, am I right? The LIBPRE value would be determined by the
configure script. Or am I wrong at some point?

This should allow some library name modifications as proposed here.
What I would like to see one day though is that I am able to produce a
library named foo.dll instead of libfoo.dll without any workarounds.
That lib prefix tends to scare Windows users, but I am sure you know
that too :-) I was not aware of possible conflicts that were mentioned
here though.




___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[Peter Rosin]

Den 2010-01-27 20:54 skrev Matěj Týč:

On Tue, 2010-01-26 at 23:26 +0800, JonY wrote:
...

I suggest the following naming scheme.

mingw.org:  libname-major.dll (unchanged)
Cygwin: cygname-major.dll (unchanged)
mingw-w64(64):  lib64name-major.dll
mingw-w64(32):  lib32name-major.dll

libtool should also check if GCC -m32 or -m64 is used, and select
the proper namespace accordingly (mingw-w64 GCC can do multilib).

Comments?



AFAIK if you use automake, you have to have something like the following
line in Makefile.am:
lib_LTLIBRARIES = libfoo.la
This means that the 'lib' prefix doesn't actually come from mingw, but
from your automake setup, right?

In order to be able to change the library name in a smarter way,
something like
lib_LTLIBRARIES = @lib...@foo.la # LIBrary PREfix
would be needed, am I right? The LIBPRE value would be determined by the
configure script. Or am I wrong at some point?

This should allow some library name modifications as proposed here.
What I would like to see one day though is that I am able to produce a
library named foo.dll instead of libfoo.dll without any workarounds.
That lib prefix tends to scare Windows users, but I am sure you know
that too :-) I was not aware of possible conflicts that were mentioned
here though.


You are mistaken. The lib prefix on the dll files is coming from
the libtool variable $libname_spec. It is typically set to something
like this:

# Format of library name prefix.
libname_spec=lib\$name

Which is then warped on Cygwin by another libtool variable, namely
$soname_spec which has a sed -e s/^lib/cyg/ in it.

A similar tweak is needed to implement this for mingw-w64.

Cheers,
Peter

--
They are in the crowd with the answer before the question.
 Why do you dislike Jeopardy?


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[Matěj Týč]

On Wed, 2010-01-27 at 22:19 +0100, Peter Rosin wrote:
 Den 2010-01-27 20:54 skrev Matěj Týč:
  On Tue, 2010-01-26 at 23:26 +0800, JonY wrote:
  ...
  I suggest the following naming scheme.
 
  mingw.org: libname-major.dll (unchanged)
  Cygwin:cygname-major.dll (unchanged)
  mingw-w64(64): lib64name-major.dll
  mingw-w64(32): lib32name-major.dll
 
  libtool should also check if GCC -m32 or -m64 is used, and select
  the proper namespace accordingly (mingw-w64 GCC can do multilib).
 
  Comments?
 
  
  AFAIK if you use automake, you have to have something like the following
  line in Makefile.am:
  lib_LTLIBRARIES = libfoo.la
  This means that the 'lib' prefix doesn't actually come from mingw, but
  from your automake setup, right?
  
  ...
 
 You are mistaken. The lib prefix on the dll files is coming from
 the libtool variable $libname_spec. It is typically set to something
 like this:
 
 # Format of library name prefix.
 libname_spec=lib\$name
 
 Which is then warped on Cygwin by another libtool variable, namely
 $soname_spec which has a sed -e s/^lib/cyg/ in it.
 
 A similar tweak is needed to implement this for mingw-w64.
 
 Cheers,
 Peter
 

Wow, this is interesting.
I remember that one guy asked about the dll prefix and he has been
advised to strip the prefix from the library name and add the '-module'
flag to libtool in order to silence complaints.
Actually, here it is:
http://lists.gnu.org/archive/html/libtool/2007-04/msg00022.html
http://lists.gnu.org/archive/html/libtool/2007-05/msg1.html

So how it is? Is there a another, more correct solution to Bob's
challenge?



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[Roumen Petrov]

Matěj Týč wrote:

On Tue, 2010-01-26 at 23:26 +0800, JonY wrote:
...

I suggest the following naming scheme.

mingw.org:  libname-major.dll (unchanged)
Cygwin: cygname-major.dll (unchanged)
mingw-w64(64):  lib64name-major.dll
mingw-w64(32):  lib32name-major.dll

libtool should also check if GCC -m32 or -m64 is used, and select
the proper namespace accordingly (mingw-w64 GCC can do multilib).

Comments?



AFAIK if you use automake, you have to have something like the following
line in Makefile.am:
lib_LTLIBRARIES = libfoo.la
This means that the 'lib' prefix doesn't actually come from mingw, but
from your automake setup, right?


No http://lists.gnu.org/archive/html/libtool/2007-07/msg00064.html

[SNIP]

This should allow some library name modifications as proposed here.
What I would like to see one day though is that I am able to produce a
library named foo.dll instead of libfoo.dll without any workarounds.
That lib prefix tends to scare Windows users, but I am sure you know
that too :-) I was not aware of possible conflicts that were mentioned
here though.



I'm not sure that idea for lib{64|32} is so good.
As I know for 32 bit process  64 bit microsoft windows os will return 
%WINDOWS%\SysWOW64 as system folder. For 64 bit process it is 
%WINDOWS%\System32 (no comment on design), Program Files for 64-bit 
and Program Files (x86)(?) for 32-bit (more on MSDN).


I'm not sure that libtool has to know how lets call it redirection work.

Roumen


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[Roumen Petrov]

Matěj Týč wrote:
[SNIP]

Wow, this is interesting.
I remember that one guy asked about the dll prefix and he has been
advised to strip the prefix from the library name and add the '-module'
flag to libtool in order to silence complaints.

[SNIP]
-module flag will install dll in $libdir and without flag in 
$libdir/..bin for stable release .


Roumen


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[Tor Lillqvist]

 I'm not sure that idea for lib{64|32} is so good.

Me neither, but,

 As I know for 32 bit process  64 bit microsoft windows os will return
 %WINDOWS%\SysWOW64 as system folder. For 64 bit process it is
 %WINDOWS%\System32

I fail to see what *that* has to do with it. Surely nobody builds any
DLL that is to be installed in the Windows system32 folder using
libtool?

--tml


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[Ralf Wildenhues]

* JonY wrote on Tue, Jan 26, 2010 at 04:26:32PM CET:
 Currently, on Win32 platforms, Cygwin uses the cyg prefix for dlls,
 and MinGW based systems uses the lib prefix.
 
 This works fine, until mingw-w64 showed up with 64bit dlls. This
 problem is especially apparent with trying to build mingw-w64 cross
 compilers.
 
 For example, both mingw and mingw-w64 builds libstdc++-6.dll from GCC.
 When installed, there might be up to 3 incompatible versions of
 libstdc++-6.dll, from mingw.org, 32bit mingw-w64 and 64bit mingw-w64.

MinGW and MinGW64 should cooperate on issues like this.  Libtool has
little to no bearing here, except to follow.  Libtool cannot decide what
the runtime system will load.

 I suggest the following naming scheme.

I suggest we follow whatever naming scheme Windows uses.  Including none
if none.  GNU libtool certainly shouldn't choose its own flavor.

 libtool should also check if GCC -m32 or -m64 is used, and select
 the proper namespace accordingly (mingw-w64 GCC can do multilib).

No, the developer should have her $PATH set correctly.

What does the Windows kernel do if it finds a needed shared library of
the wrong ABI early in $PATH while trying to start a program?  Fail or
skip, and if skip, silently or verbosely?

Thanks,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[Alon Bar-Lev]

On Tue, Jan 26, 2010 at 5:26 PM, JonY jo...@users.sourceforge.net wrote:
 Hi,

 Currently, on Win32 platforms, Cygwin uses the cyg prefix for dlls,
 and MinGW based systems uses the lib prefix.

 This works fine, until mingw-w64 showed up with 64bit dlls. This
 problem is especially apparent with trying to build mingw-w64 cross
 compilers.

 For example, both mingw and mingw-w64 builds libstdc++-6.dll from GCC.
 When installed, there might be up to 3 incompatible versions of
 libstdc++-6.dll, from mingw.org, 32bit mingw-w64 and 64bit mingw-w64.

 I suggest the following naming scheme.

 mingw.org:      libname-major.dll (unchanged)
 Cygwin:         cygname-major.dll (unchanged)
 mingw-w64(64):  lib64name-major.dll
 mingw-w64(32):  lib32name-major.dll

 libtool should also check if GCC -m32 or -m64 is used, and select
 the proper namespace accordingly (mingw-w64 GCC can do multilib).

 Comments?


This is highly none standard naming convention...
Handling w32 and w64 should be the same as handling multilib at Linux
for example.

Alon.


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[JonY]

On 1/26/2010 23:52, Alon Bar-Lev wrote:

On Tue, Jan 26, 2010 at 5:26 PM, JonYjo...@users.sourceforge.net  wrote:

Hi,

Currently, on Win32 platforms, Cygwin uses the cyg prefix for dlls,
and MinGW based systems uses the lib prefix.

This works fine, until mingw-w64 showed up with 64bit dlls. This
problem is especially apparent with trying to build mingw-w64 cross
compilers.

For example, both mingw and mingw-w64 builds libstdc++-6.dll from GCC.
When installed, there might be up to 3 incompatible versions of
libstdc++-6.dll, from mingw.org, 32bit mingw-w64 and 64bit mingw-w64.

I suggest the following naming scheme.

mingw.org:  libname-major.dll (unchanged)
Cygwin: cygname-major.dll (unchanged)
mingw-w64(64):  lib64name-major.dll
mingw-w64(32):  lib32name-major.dll

libtool should also check if GCC -m32 or -m64 is used, and select
the proper namespace accordingly (mingw-w64 GCC can do multilib).

Comments?



This is highly none standard naming convention...
Handling w32 and w64 should be the same as handling multilib at Linux
for example.

Alon.




Hi,

on Linux, I believe .so files go into /lib and lib{32,64}, not so on
Windows/MinGW, they go into the bindir.

So installing 32bit and 64bit dlls together into bindir is problematic.

The win32 dll loading is also not lenient, a 32bit exe encountering a 
64bit dll will not load at all, unless there is a way to make PATH

different for 32bit and 64bit executables.


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Extend libtool dll namespaces for mingw-w64

[Bob Friesenhahn]

On Tue, 26 Jan 2010, Alon Bar-Lev wrote:


libtool should also check if GCC -m32 or -m64 is used, and select
the proper namespace accordingly (mingw-w64 GCC can do multilib).

Comments?



This is highly none standard naming convention...
Handling w32 and w64 should be the same as handling multilib at Linux
for example.


Windows uses a dramatically different algorithm than Linux to find DLL 
libraries at run-time.  Windows also uses a split model where the link 
library is separate from the object DLL library.  I think that using a 
special naming convention may be warranted for Windows.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/


___
http://lists.gnu.org/mailman/listinfo/libtool