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

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

JonY
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.



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

marco atzeri-4
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

Reply | Threaded
Open this post in threaded view
|

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

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
>
> --
> 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?


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

marco atzeri-4
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

Reply | Threaded
Open this post in threaded view
|

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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>
  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 <[hidden email]>
  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
"--Problem reports:       http://cygwin.com/problems.htmlFAQ:                   http://cygwin.com/faq/Documentation:         http://cygwin.com/docs.htmlUnsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple"
Reply | Threaded
Open this post in threaded view
|

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[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 <[hidden email]>
>   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 <[hidden email]>
>   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.


"--Problem reports:       http://cygwin.com/problems.htmlFAQ:                   http://cygwin.com/faq/Documentation:         http://cygwin.com/docs.htmlUnsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple"

signature.asc (849 bytes) Download Attachment