[ANNOUNCEMENT] Updated: binutils-2.34-1 (x86/x86_64)

[ANNOUNCEMENT] Updated: binutils-2.34-1 (x86/x86_64)

[JonY]

[-- Attachment #1.1: Type: text/plain, Size: 707 bytes --]

The following packages have been uploaded to the Cygwin distribution:

* binutils-2.34

This version was tested by building gcc-9.2.0.


              *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com <at> cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ANNOUNCEMENT] Updated: binutils-2.34-1 (x86/x86_64)

[Marco Atzeri]

Am 26.02.2020 um 11:35 schrieb JonY:
> The following packages have been uploaded to the Cygwin distribution:
> 
> * binutils-2.34
> 
> This version was tested by building gcc-9.2.0.
> 

It seems there is a regression about -lpthread

*** Warning: linker path does not have real file for library -lpthread.
*** 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 libpthread and none of the candidates passed a file format test
*** using a file magic. Last file checked: /lib/libpthread.a

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: binutils-2.34-1 (x86/x86_64)

[JonY]

[-- Attachment #1.1: Type: text/plain, Size: 1229 bytes --]

On 2/29/20 7:23 PM, Marco Atzeri wrote:
> Am 26.02.2020 um 11:35 schrieb JonY:
>> The following packages have been uploaded to the Cygwin distribution:
>>
>> * binutils-2.34
>>
>> This version was tested by building gcc-9.2.0.
>>
> 
> It seems there is a regression about -lpthread
> 
> *** Warning: linker path does not have real file for library -lpthread.
> *** 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 libpthread and none of the candidates passed a file format test
> *** using a file magic. Last file checked: /lib/libpthread.a
> 
> -- 
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> 

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?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ANNOUNCEMENT] Updated: binutils-2.34-1 (x86/x86_64)

[Marco Atzeri]

Am 01.03.2020 um 03:18 schrieb JonY:
> On 2/29/20 7:23 PM, Marco Atzeri wrote:
>> Am 26.02.2020 um 11:35 schrieb JonY:
>>> The following packages have been uploaded to the Cygwin distribution:
>>>
>>> * binutils-2.34
>>>
>>> This version was tested by building gcc-9.2.0.
>>>
>>
>> It seems there is a regression about -lpthread
>>
>> *** Warning: linker path does not have real file for library -lpthread.
>> *** 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 libpthread and none of the candidates passed a file format test
>> *** using a file magic. Last file checked: /lib/libpthread.a
>>
>> -- 
>>
> 
> 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

*** Warning: linker path does not have real file for library -lpthread.
*** 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 libpthread and none of the candidates passed a file format test
*** using a file magic. Last file checked: /lib/libpthread.a

*** Warning: linker path does not have real file for library -lrt.
*** 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 librt and none of the candidates passed a file format test
*** using a file magic. Last file checked: /lib/librt.a

*** Warning: linker path does not have real file for library -ldl.
*** 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 libdl and none of the candidates passed a file format test
*** using a file magic. Last file checked: /lib/libdl.a
*** 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.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.


When I remove the "-lpthread -lrt -ldl" from the libtool invocation 
everything is fine

Regards
Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Cygwin libtool confused about link library

[JonY]

[-- Attachment #1.1: Type: text/plain, Size: 1728 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Cygwin libtool confused about link library

[Simon Marchi]

> 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[d000000.o]: libdl_dll_iname I 0000000000000000

With binutils 2.34, the corresponding line is:

  /usr/lib/libdl.a[d000000.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 <amodra@gmail.com>
  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 <amodra@gmail.com>
  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

Re: Cygwin libtool confused about link library

[JonY]

[-- Attachment #1.1: Type: text/plain, Size: 2169 bytes --]

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[d000000.o]: libdl_dll_iname I 0000000000000000
> 
> With binutils 2.34, the corresponding line is:
> 
>   /usr/lib/libdl.a[d000000.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 <amodra@gmail.com>
>   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 <amodra@gmail.com>
>   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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]