[PATCH] libtool: Cygwin does not use DOS based filesystem

[JonY]

Even though it runs on Windows, Cygwin uses UNIX paths.
The _WIN32 macro may still be defined when using Win32 APIs
however.

Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
 build-aux/ltmain.in | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 96b37003..3bb3043e 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -3711,8 +3711,8 @@ int setenv (const char *, const char *, int);
 # define PATH_SEPARATOR ':'
 #endif

-#if defined _WIN32 || defined __MSDOS__ || defined __DJGPP__ || \
-  defined __OS2__
+#if (defined _WIN32 && ! defined __CYGWIN__) || defined __MSDOS__ || \
+  defined __DJGPP__ || defined __OS2__
 # define HAVE_DOS_BASED_FILE_SYSTEM
 # define FOPEN_WB "wb"
 # ifndef DIR_SEPARATOR_2
-- 
2.26.1



signature.asc
Description: OpenPGP digital signature

Re: Cygwin libtool confused about link library

[JonY]

On 3/9/20 9:01 PM, Simon Marchi wrote:
>> Hello libtool folks,
>> Any ideas about this? Something confused the file magic command?
>> dlltool --identify does show libdl.a is associated with cygwin1.dll for
>> example.
> 
> Hi,
> 
> I stumbled on this and dug into libtool, here's what I found.
> 
> As part of the process of identifying the nature these libraries, libtool uses
> this nm + sed snippet [1]:
> 
>   win32_nmres=`eval $NM -f posix -A \"$func_to_tool_file_result\" |
> $SED -n -e '
>   1,100{
>   / I /{
>   s|.*|import|
>   p
>   q
>   }
>   }'`
>   ;;
> 
> The sed scripts looks for a line containing the " I " string.
> 
> With binutils < 2.34, the nm output looked like:
> 
>   /usr/lib/libdl.a[d00.o]: libdl_dll_iname I 
> 
> With binutils 2.34, the corresponding line is:
> 
>   /usr/lib/libdl.a[d00.o]: libdl_dll_iname D 0
> 
> And therefore the library is mis-identified.
> 
> The commit that introduced this regression is:
> 
>   commit a288c270991de1578ad28ac312120f4167347234
>   Author: Alan Modra 
>   Date:   Fri May 3 21:36:46 2019 +0930
> 
>   PR24511, nm should not mark symbols in .init_array as "t"
> 
> I tried building the latest commit on the binutils-2_34-branch, and the 
> behavior
> has been restored (the line shows " I " again).  The commit that restored the
> behavior is:
> 
>   commit 40bfb9762747f8336b17c70a0173d10200fa62eb
>   Author: Alan Modra 
>   Date:   Thu Feb 27 17:28:47 2020 +1030
> 
>   Re: PR24511, nm should not mark symbols in .init_array as "t"
> 
> So this should all go back to normal when there is a binutils 2.34.1 release 
> and it is
> packaged by Cygwin.  In the mean time, the commit that restored the behavior 
> could maybe
> be backported in the Cygwin package, but I don't know what the habits are in 
> Cygwin for
> this kind of thing.
> 
> Simon
> 
> [1] 
> https://github.com/autotools-mirror/libtool/blob/b9b44533fbf7c7752ffd255c3d09cc360e24183b/build-aux/ltmain.in#L3050-L3059
> 

Thanks for investigating, I'll see about doing a new binutils release.



signature.asc
Description: OpenPGP digital signature

Cygwin libtool confused about link library

[JonY]

On 3/1/20 11:00 AM, Marco Atzeri wrote:
>>
>> Last file checked: /lib/libpthread.a
>>
>> Is that correct? Do you have the complete command line? Is this
>> happening on both archs or just i686?
>>
> 
> both archs.
> The error is likely coming from libtool and it is valid for all the 3
> libraries "-lpthread -lrt -ldl" , so I assume the current binutils is
> providing some feedback different than in the past to libtool
> 
> I tested again the build of gdal-3.0.2-2 that before the
> update of gcc and binutils was working fine.
> 
> I shorted the command line as the amount of object is very very large:
> 
> /bin/sh
> /cygdrive/d/cyg_pub/devel/gdal/prova302/gdal-3.0.2-2.x86_64/build/libtool 
> --mode=link
> --silent g++   -lcrypto -ljson-c -lqhull -L/usr/lib -lgeos_c -lwebp 
> -lsqlite3 -lodbc32 -lodbccp32 -lexpat -lopenjp2  -L/usr/lib -lnetcdf
> -lhdf5 -lgif -ljpeg -lgeotiff -ltiff -lpng -lcfitsio -lpq -lproj -lz
> -lpthread -lrt -ldl  -lws2_32 -lpsapi -lpcre -lcurl -liconv -L/usr/lib
> -lxml2 -lz -llzma -liconv -lm -o libgdal.la ./ogr/gml2ogrgeometry.lo
> ./ogr/ogr2gmlgeometr
> y.lo ./ogr/ogr_api.lo ..
> 
> /cygdrive/d/cyg_pub/devel/gdal/prova302/gdal-3.0.2-2.x86_64/build/third_party/o/RLE.lo
> \
>     -rpath /usr/lib \
>     -no-undefined \
>     -version-info 26:2:0
> 

I was a bit confused for a moment, but this looks like the cygwin
builds, not cross compiles.

My current (horrible hack)workaround is to edit the libtool script, change:
deplibs_check_method="pass_all"



Hello libtool folks,
Any ideas about this? Something confused the file magic command?
dlltool --identify does show libdl.a is associated with cygwin1.dll for
example.



signature.asc
Description: OpenPGP digital signature

Re: Forced static lib if any depend lib is static on win32

[JonY]

On 4/19/2014 09:22, Evgeny Grin wrote:
 
 
 19.04.2014, 04:45, JonY:
 On 4/19/2014 03:31, Evgeny Grin wrote:
  For XBMC we have 41 depend precompiled lib, 4 of them depend on zlib dll, 
 all of 4 depend on zlib1.dll, but each one on specific zlib version. And 
 with some zlib versions some of depend dlls crash.
  But it's just an example. Sometimes only a small fraction of lib functions 
 is used, so it's better and wiser to statically link only those functions 
 for shared lib and not redistribute heavy additional dll with your dll.
  There are far more possibile good uses for static libs in shared libs.
  MS dev tools allow any combinations of shared/static link, why libtool 
 give worse possible options?

 I think you should be cleaning house, instead of allowing random bits
 and bobs to connect together. The real problem is that you have 4
 incompatible versions of zlib1.dll in the first place.
 
 Of course cleaning is required, but it's not always possible to simple 
 rebuild some particular lib on Win32.
 But I was talking about ability to link static in shared.
 

This is relevant, it is what kicked off the discussion. How about a
tighter reign over what gets contributed instead of randomly accepting
executable code?

 Libtool is good at preventing multiple exports on win32, I have seen
 disasters where zlib is exported *multiple* times in different DLLs of
 the same project because the author does not know what is going on. At
 least it was a compatible and same version of zlib.
 
 Right, it's nice idea to prevent static link for shared lib that blindly use 
 --export-all-symbols. But for well-designed libs that use dllexport 
 attribute or def-file disallowing static libs is just obstacle.
 

You have to remember, using static libs with shared DLLs in itself is a
bad idea, you still end up with *multiple* instance of it at runtime as
well, even if it is not exported, moving the problem from link time to
run time.

Above all, --export-all-symbols is default behavior in the absents of
any dllexport attributes or def files, so yes, blocking static libraries
is justified without introducing PE specific scanning rules.

  Didn't see anything that prevent linking static libs in shared libs.
  Additionally libtool can track if some particular lib use 
 dllexport/def-files or simple export of all symbols.

 The difference is that convenience are purely used build time only, they
 are never ever installed. It is convenient when you have enough object
 files to overrun the OS command line length limit.

 I'm not sure you want convenient dlls that aren't installed, they don't
 make sense.
 
 Ok, I got the advantage of libtool, but still don't understand why this 
 should prevent linking static libs in well-designed shared lib?
 

Your best option is either go entirely static or DLLs only. Going
somewhere in between is just plain trouble on Windows.




signature.asc
Description: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Forced static lib if any depend lib is static on win32

[JonY]

On 4/19/2014 03:31, Evgeny Grin wrote:
 
 
 18.04.2014, 19:25, Bob Friesenhahn bfrie...@simple.dallas.tx.us:
 For Win32 builds on my Windows system, I see that it is normal for
 DLLs to be named according to the major interface number.  For
 example, zlib (not created using libtool) is named zlib1.dll and
 libltdl (created using libtool) is named libltdl-7.dll.  This is not
 as convenient as ELF versioning, but does prevent disaster.  Why is
 this not the case for your system?
 
 For XBMC we have 41 depend precompiled lib, 4 of them depend on zlib dll, all 
 of 4 depend on zlib1.dll, but each one on specific zlib version. And with 
 some zlib versions some of depend dlls crash.
 But it's just an example. Sometimes only a small fraction of lib functions is 
 used, so it's better and wiser to statically link only those functions for 
 shared lib and not redistribute heavy additional dll with your dll.
 There are far more possibile good uses for static libs in shared libs.
 MS dev tools allow any combinations of shared/static link, why libtool give 
 worse possible options?
 

I think you should be cleaning house, instead of allowing random bits
and bobs to connect together. The real problem is that you have 4
incompatible versions of zlib1.dll in the first place.

Libtool is good at preventing multiple exports on win32, I have seen
disasters where zlib is exported *multiple* times in different DLLs of
the same project because the author does not know what is going on. At
least it was a compatible and same version of zlib.

 Libtool convenience libraries do support DLL exports but this is
 because libtool built them and so it knows how they are built.  In
 fact, libtool convenience libraries are not used like libraries at all
 and are simply a convenient reference to a collection of object files
 wrapped in an archive.
 
 Didn't see anything that prevent linking static libs in shared libs.
 Additionally libtool can track if some particular lib use 
 dllexport/def-files or simple export of all symbols.

The difference is that convenience are purely used build time only, they
are never ever installed. It is convenient when you have enough object
files to overrun the OS command line length limit.

I'm not sure you want convenient dlls that aren't installed, they don't
make sense.




signature.asc
Description: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[JonY]

On 9/10/2013 02:12, Ozkan Sezer wrote:
 
 *** Warning: linker path does not have real file for library -lole32.
 *** I have the capability to make that library automatically link in when
 *** you link to this library.  But I can only do this if you have a
 *** shared version of the library, which you do not appear to have
 *** because I did check the linker path looking for a file starting
 *** with libole32 but no candidates were found. (...for file magic test)
 
 *** Warning: linker path does not have real file for library -ldsound.
 *** I have the capability to make that library automatically link in when
 *** you link to this library.  But I can only do this if you have a
 *** shared version of the library, which you do not appear to have
 *** because I did check the linker path looking for a file starting
 *** with libdsound but no candidates were found. (...for file magic test)
 
 *** Warning: linker path does not have real file for library -lwinmm.
 *** I have the capability to make that library automatically link in when
 *** you link to this library.  But I can only do this if you have a
 *** shared version of the library, which you do not appear to have
 *** because I did check the linker path looking for a file starting
 *** with libwinmm but no candidates were found. (...for file magic test)
 *** The inter-library dependencies that have been dropped here will be
 *** automatically added whenever a program is linked with this library
 *** or is declared to -dlopen it.
 
 I am stuck with this. Can anyone see what I am doing wrong?
 

This needs to be taken up with the libtool developers.

libtool is technically correct, but libole32.a is a mixed shared lib
with static data inserted.

libtool should use dlltool --identify when available.




signature.asc
Description: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: mingw-w64's libuuid.a : *** Warning: linker path does not have real file for library -luuid.

[JonY]

On 7/22/2012 00:43, Peter Rosin wrote:
 On 2012-07-21 14:49, Vincent Torri wrote:
 On Sat, Jul 21, 2012 at 2:41 PM, Peter Rosin p...@lysator.liu.se wrote:
 On 2012-07-21 13:16, Vincent Torri wrote:
 another solution is to just kill the stupid .la file. There is

 I don't think the .la file is stupid as it lists other important
 dependencies.

 so what ? There is a HUGE problem, here. Currently, if a lib uses
 symbols in libuuid, it just can't be used to create progs/shared lib
 because the .la file lists it while it should (must) not. Static libs
 must not appear in the dependency_libs field.
 
 Oh, but static libs do need to be listed in dependency_libs as long
 as there is no other place to put them. That, or static linking is not
 working well at all. I'm not willing to sacrifice static linking.
 
 absolutely NO reason to add to the linker static libraries that are
 ONLY used in my Evil library and that are not used elsewhere.

 I think that it is the best solution

 That disables (easy) static linking. I, as a library author, do not
 like to make that policy decision for the application author.

 on Windows  DLL are good. I already pass --disable-static to all my
 Windows builds.
 
 That has been argued elsewhere, but I can still see the value of the
 other side. So again, I, as a library author, do not like to shove that
 policy decision down the throat of my library consumers.

So how are you supposed to build it if *I* want it as a DLL?

Rhetoric notwithstanding, how are you supposed to build a DLL that uses
libuuid.a? No, cloning UUID constants is not a proper fix.



signature.asc
Description: OpenPGP digital signature
___
https://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

[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

[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

[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

[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

[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

[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

[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

Extend libtool dll namespaces for mingw-w64

[JonY]

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?


___
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