Re: Cygwin libtool confused about link library

2020-03-09 Thread 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

2020-03-01 Thread 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