* [ANNOUNCEMENT] Updated: binutils-2.34-1 (x86/x86_64)
@ 2020-02-26 10:40 JonY
2020-02-29 19:23 ` Marco Atzeri
0 siblings, 1 reply; 7+ messages in thread
From: JonY @ 2020-02-26 10:40 UTC (permalink / raw)
To: cygwin
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ANNOUNCEMENT] Updated: binutils-2.34-1 (x86/x86_64)
2020-02-26 10:40 [ANNOUNCEMENT] Updated: binutils-2.34-1 (x86/x86_64) JonY
@ 2020-02-29 19:23 ` Marco Atzeri
2020-03-01 2:18 ` JonY
0 siblings, 1 reply; 7+ messages in thread
From: Marco Atzeri @ 2020-02-29 19:23 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ANNOUNCEMENT] Updated: binutils-2.34-1 (x86/x86_64)
2020-02-29 19:23 ` Marco Atzeri
@ 2020-03-01 2:18 ` JonY
2020-03-01 11:00 ` Marco Atzeri
0 siblings, 1 reply; 7+ messages in thread
From: JonY @ 2020-03-01 2:18 UTC (permalink / raw)
To: cygwin
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ANNOUNCEMENT] Updated: binutils-2.34-1 (x86/x86_64)
2020-03-01 2:18 ` JonY
@ 2020-03-01 11:00 ` Marco Atzeri
2020-03-01 13:02 ` Cygwin libtool confused about link library JonY
0 siblings, 1 reply; 7+ messages in thread
From: Marco Atzeri @ 2020-03-01 11:00 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Cygwin libtool confused about link library
2020-03-01 11:00 ` Marco Atzeri
@ 2020-03-01 13:02 ` JonY
2020-03-09 21:01 ` Simon Marchi
0 siblings, 1 reply; 7+ messages in thread
From: JonY @ 2020-03-01 13:02 UTC (permalink / raw)
To: The Cygwin Mailing List, Libtool List
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Cygwin libtool confused about link library
2020-03-01 13:02 ` Cygwin libtool confused about link library JonY
@ 2020-03-09 21:01 ` Simon Marchi
2020-03-09 23:19 ` JonY
0 siblings, 1 reply; 7+ messages in thread
From: Simon Marchi @ 2020-03-09 21:01 UTC (permalink / raw)
To: 10walls; +Cc: cygwin
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Cygwin libtool confused about link library
2020-03-09 21:01 ` Simon Marchi
@ 2020-03-09 23:19 ` JonY
0 siblings, 0 replies; 7+ messages in thread
From: JonY @ 2020-03-09 23:19 UTC (permalink / raw)
To: Simon Marchi; +Cc: cygwin, Libtool List
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-03-09 23:20 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-26 10:40 [ANNOUNCEMENT] Updated: binutils-2.34-1 (x86/x86_64) JonY
2020-02-29 19:23 ` Marco Atzeri
2020-03-01 2:18 ` JonY
2020-03-01 11:00 ` Marco Atzeri
2020-03-01 13:02 ` Cygwin libtool confused about link library JonY
2020-03-09 21:01 ` Simon Marchi
2020-03-09 23:19 ` JonY
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).