Re: [ANNOUNCEMENT] Updated: binutils-2.34-1 (x86/x86_64)
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
Re: [ANN] Cygwin-OpenSSH 8.2.2.2
Bill Stewart writes: > I have removed the package. (The phrase "no good deed goes unpunished" > comes to mind.) I don't think anybody assumed any bad intentions on your part and it just was to make you aware of the licensing problem and ask you to fix it. The GPL's stated purpose istp protect the freedom of the user, not necessarily the convenience of the distributor (or even the user). > I will put up a separate package later that does not contain any cygwin > binaries and write a script instead that can download the needed binaries > and sources using the cygwin setup tool (that the user will have to > download themselves). In this way I will be hosting no binaries and will > not be in violation of any license. Unless you are using setup.exe to do that, please ensure that you use a secure method for downloading the setup.ini file and the signature, actually check the validity of the signature and then proceed to checksum the downloaded files before installation. https://cygwin.com/faq.html#faq.setup.install-security https://cygwin.com/faq.html#faq.setup.increase-install-security https://cygwin.com/install.html If you so use setup.exe, note that it is GPLv2 licensed. Since there is no source package, you will instead have to point your installer to get a Git snapshot if the user requests the source. Again, if you use that binary, please use a secure transport and check it against the signature, also obtained via secure transport. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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
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: Change in logical link behaviour
Hi Andrey,
Am 01.03.2020 um 02:52 schrieb Andrey Repin:
>> I try to reliably determine if native Windows symlink are working for a
>> current cygwin environment in a shell script.
>
>> Therefor I used a powershell snipped:
>
>> mkdir asdfgh
>> ln -s asdfgh/ asdfgh-1
>> powershell "& {Get-Item -Path asdfgh-1 | Select-Object}"
>
>> On cygwin 3.0.7 the output is as follows:
>
>
>> Directory: D:\cygwin\home\rainer\temp
>
>
>> ModeLastWriteTime Length Name
>> - --
>> dl 29.02.2020 13:58asdfgh-1
>
>> On cygwin 3.1.4 I get:
>
>
>> Directory: D:\cygwin\home\rainer\temp
>
>
>> ModeLastWriteTime Length Name
>> - --
>> d29.02.2020 13:58asdfgh-1
>
>> So now there is no indication that this is a link. Is this new behaviour
>> intended or a bug?
>
>> I did not try on Windows 10, I'm still on windows 7.
>
> I get the same behavior is not using Cygwin to create the link at all, this is
> probably a change in how Cygwin interprets symlinks.
I don't know what's going on here. The only difference is the cygwin
version. So, the different behaviour is caused by cygwin while creating
the link, for sure!
Somebody any idea?
Rainer
signature.asc
Description: OpenPGP digital signature
flexdll error: cannot relocate RELOC_REL32
Dear Cygwin development team and Cygwin experts, I use Cygwin-64 on windows and get a fork problem when I try to manually install menhir package. 0 [main] ocamlrun 1615 child_info_fork::abort: address space needed by 'dllunix.so' (0x40) is already occupied /usr/bin/ocamldep.opt -modules menhir.ml > menhir.ml.depends 0 [main] ocamlrun 1616 child_info_fork::abort: address space needed by 'dllunix.so' (0x40) is already occupied /cygdrive/g/Cygwin/menhir-20190924/src/_stage1/myocamlbuild: "fork" failed: Resource temporarily unavailable I follow online suggestion to run "/usr/bin/rebaseall -v" using ash.exe. However, I get another program after that: Fatal error: cannot load shared library dllunix Reason: flexdll error: cannot relocate RELOC_REL32, target is too far: 0xfffc02088b5f 0x2088b5f I searched solutions for this new problem. Most solutions are to manually rebase dllunix to a lower number like 0x0644. However, I cannot do that. Here is what I get in Cygwin: $ rebase -b 0x0644 /usr/lib/ocaml/stublibs/dllunix.so rebase: Invalid Baseaddress 0x0644, must be > 0x2 So, what should I do to this problem? Also, if I did not use "/usr/bin/rebaseall -v" using ash.exe, but follow FAQ's suggestion (run "rebase-trigger fullrebase" in Cygwin), then I cannot solve the fork problem and still get 0 [main] ocamlrun 1615 child_info_fork::abort: address space needed by 'dllunix.so' (0x40) is already occupied /usr/bin/ocamldep.opt -modules menhir.ml > menhir.ml.depends 0 [main] ocamlrun 1616 child_info_fork::abort: address space needed by 'dllunix.so' (0x40) is already occupied /cygdrive/g/Cygwin/menhir-20190924/src/_stage1/myocamlbuild: "fork" failed: Resource temporarily unavailable Thank you very much! Qinxiang Cao Shanghai Jiao Tong University, John Hopcroft Center Room 1110-2, SJTUSE Building 800 Dongchuan Road, Shanghai, China, 200240 -- 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
[ANNOUNCEMENT] Updated: Perl distributions
The following Perl distributions have been updated to their latest version on CPAN, respectively: x86/x86_64 -- perl-DateTime-1.52-1 noarch -- perl-DateTime-Format-Strptime-1.77-1 perl-HTTP-Message-6.22-1 perl-List-AllUtils-0.16-1 perl-Test-Deep-1.130-1 -- *** 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@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. -- 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
cat /proc/partitions shows only devices, not partitions
This was an issue that I had previously in September of last year and sent the
issue to this mailing list ("win-mounts no longer displays anything when doing
"cat /proc/partitions") but the issue stopped occurring before I could get
around to diagnosing it. This issue has now re-occurred and this time it seems
permanent. When I run:
$ cat /proc/partitions
major minor #blocks name win-mounts
8 0 0 sda
816 0 sdb
832 0 sdc
848 0 sdd
864 0 sde
880 0 sdf
...I see nothing at all in the win-mounts column. This makes it impossible for
me to see which Windows drive letter maps to which /dev/sdX entry. On closer
inspection, this seems to be because I'm not actually seeing any partitions of
my drives, even though there are many - for example, I see /dev/sda but no
/dev/sda1 or /dev/sda2, and because it's the partitions that are mounted, it's
this that seems to result in me seeing nothing in the win-mounts column. I'm
running Cygwin on Windows 7 (yes I'm aware it's EOL).
For testing purposes I also ran the following command (for obvious reasons I
don't want to have run something like this to find my drive mappings):
$ for disk in /dev/sd*; do echo -n $disk$'\t'; cygpath -m $disk; done
/dev/sda//./PhysicalDrive0
/dev/sda1 //./D:
/dev/sdb//./PhysicalDrive1
/dev/sdc//./PhysicalDrive2
/dev/sdc1 //./Volume{88cc26b4-e0e5-11e9-9cc4-806e6f6e6963}
/dev/sdc2 //./C:
/dev/sdd//./PhysicalDrive3
/dev/sdd1 //./B:
/dev/sde//./PhysicalDrive4
/dev/sde1 //./HarddiskVolume5
/dev/sde2 //./E:
/dev/sdf//./PhysicalDrive5
/dev/sdf1 //./I:
Thanks in advance for any help with this, it would be very much appreciated as
I rely on Cygwin a lot.
Why is taskset still not in util-linux?
Dear cygwin-ers -- Something I had asked about a while ago was the absence os taskset in cygwin's util-linux. At the time, it was pointed out that the necessary get/set affinity library/system calls were not yet supported. These were added a while ago, so it would seem that taskset ought to work. In fact, I think someone got it going on their own. Can we add it to util-linux now, officially? I think this was intended but perhaps was overlooked or something. Regards - Eliot Moss -- 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: flexdll error: cannot relocate RELOC_REL32
On 2020-03-01 11:35, Cao Qinxiang wrote: > Dear Cygwin development team and Cygwin experts, > > I use Cygwin-64 on windows and get a fork problem when I try to manually > install menhir package. > > > 0 [main] ocamlrun 1615 child_info_fork::abort: address space needed by > 'dllunix.so' (0x40) is already occupied > /usr/bin/ocamldep.opt -modules menhir.ml > menhir.ml.depends > 0 [main] ocamlrun 1616 child_info_fork::abort: address space needed > by 'dllunix.so' (0x40) is already occupied > /cygdrive/g/Cygwin/menhir-20190924/src/_stage1/myocamlbuild: "fork" failed: > Resource temporarily unavailable > > > I follow online suggestion to run "/usr/bin/rebaseall -v" using ash.exe. > However, I get another program after that: > > > > Fatal error: cannot load shared library dllunix > Reason: flexdll error: cannot relocate RELOC_REL32, target is too far: > 0xfffc02088b5f 0x2088b5f > > > I searched solutions for this new problem. Most solutions are to manually > rebase dllunix to a lower number like 0x0644. However, I cannot > do that. Here is what I get in Cygwin: > > > $ rebase -b 0x0644 /usr/lib/ocaml/stublibs/dllunix.so > rebase: Invalid Baseaddress 0x0644, must be > 0x2 > > > So, what should I do to this problem? > > Also, if I did not use "/usr/bin/rebaseall -v" using ash.exe, but follow > FAQ's suggestion (run "rebase-trigger fullrebase" in Cygwin), then I cannot > solve the fork problem and still get > > 0 [main] ocamlrun 1615 child_info_fork::abort: address space needed by > 'dllunix.so' (0x40) is already occupied > /usr/bin/ocamldep.opt -modules menhir.ml > menhir.ml.depends > 0 [main] ocamlrun 1616 child_info_fork::abort: address space needed > by 'dllunix.so' (0x40) is already occupied > /cygdrive/g/Cygwin/menhir-20190924/src/_stage1/myocamlbuild: "fork" failed: > Resource temporarily unavailable > Run rebase-trigger full then shut down *ALL* Cygwin processes: check Task Manager Details tab Image path name column for process paths under Cygwin root and kill. If rebase-trigger full fails, create /var/cache/rebase/fullrebase. Then download and run Cygwin setup and let all the postinstall scripts complete. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- 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: flexdll error: cannot relocate RELOC_REL32
On 2020-03-01 11:35, Cao Qinxiang wrote: > Dear Cygwin development team and Cygwin experts, > > I use Cygwin-64 on windows and get a fork problem when I try to manually > install menhir package. > > > 0 [main] ocamlrun 1615 child_info_fork::abort: address space needed by > 'dllunix.so' (0x40) is already occupied > /usr/bin/ocamldep.opt -modules menhir.ml > menhir.ml.depends > 0 [main] ocamlrun 1616 child_info_fork::abort: address space needed > by 'dllunix.so' (0x40) is already occupied > /cygdrive/g/Cygwin/menhir-20190924/src/_stage1/myocamlbuild: "fork" failed: > Resource temporarily unavailable > > > I follow online suggestion to run "/usr/bin/rebaseall -v" using ash.exe. > However, I get another program after that: > > > > Fatal error: cannot load shared library dllunix > Reason: flexdll error: cannot relocate RELOC_REL32, target is too far: > 0xfffc02088b5f 0x2088b5f > > > I searched solutions for this new problem. Most solutions are to manually > rebase dllunix to a lower number like 0x0644. However, I cannot > do that. Here is what I get in Cygwin: > > > $ rebase -b 0x0644 /usr/lib/ocaml/stublibs/dllunix.so > rebase: Invalid Baseaddress 0x0644, must be > 0x2 > > > So, what should I do to this problem? > > Also, if I did not use "/usr/bin/rebaseall -v" using ash.exe, but follow > FAQ's suggestion (run "rebase-trigger fullrebase" in Cygwin), then I cannot > solve the fork problem and still get > > 0 [main] ocamlrun 1615 child_info_fork::abort: address space needed by > 'dllunix.so' (0x40) is already occupied > /usr/bin/ocamldep.opt -modules menhir.ml > menhir.ml.depends > 0 [main] ocamlrun 1616 child_info_fork::abort: address space needed > by 'dllunix.so' (0x40) is already occupied > /cygdrive/g/Cygwin/menhir-20190924/src/_stage1/myocamlbuild: "fork" failed: > Resource temporarily unavailable > Run rebase-trigger full then shut down *ALL* Cygwin processes: check Task Manager Details tab Image path name column for process paths under Cygwin root and kill. If rebase-trigger full fails, create /var/cache/rebase/fullrebase. Then download and run Cygwin setup and let all the postinstall scripts complete. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- 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
