Re: Using ARM GNU GCC with Cygwin
On 2020-04-08 14:13, Ben Kamen wrote: Well then. This certainly turned out to be all sorts of interesting discussion. :) I for one also can say it's nice to have a cygwin environment over DOS if I'm forced to a CLI on Windows. Most of my days are spent on Linux -- but it looks like I have some legit CLI time coming on Windows and cygwin was my first go-to thought for that. It's already bad enough how many times I type 'ls -l' in DOS to get an error. HAhahaha. (two thumbs up) I use Cygwin for porting a programming language (TXR) to Windows. Previously, I used MinGW, which was terrible; it has no POSIX support at all. The MinGW version didn't have a working REPL mode, for instance. Cygwin has termios calls that translate to the Windows Console API; you can put the TTY into raw mode and just spew ANSI/VT100 codes and it all works. Input side too. In 2016(?), Cygwin announced that the DLL's were going to be LGPL instead of GPL. That means they could be linked not only with proprietary applications, but ones with *less* restrictive licensing such as BSD, without GPL contagion, like my project. Terrific! I immediately saw the implications for this, and began work on a forked version of the Cygwin DLL which is a little bit more suitable as a run-time for a Windows application. I made just a few changes for more Windows-like behaviors. For instance, the file system calls understand Windows paths with letter names instead of /cygdrv, and the chdir() system call understands the "logged drive" DOS/Windows concept. The PATH variable is untranslated in Cygnal, and semicolon separated. The system() function and popen() don't look for /bin/sh, they use the CMD variable, defaulting on cmd.exe. Things like that. That project is here: https://www.kylheku.com/cygnal/ The beauty is that you can compile a program quite simply in Cygwin as a Cygwin executable. Then just slide this modified library under it, bundle them together, and ship it as a Windows program. I do exactly that. Cygnal is a little behind Cygwin; it's about time I did a rebase to a newer Cygwin. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Using ARM GNU GCC with Cygwin
On 2020-04-08 13:58, David Rothenberger wrote: On 4/8/2020 1:50 PM, Kaz Kylheku via Cygwin wrote: On 2020-04-04 11:58, Åke Rehnman via Cygwin wrote: I have a major use case for Cygwin for providing remote access to Windows. Using a non-Cygwin utility called "RunAsService.EXE", I turned a Cygwin Bash script into a Windows service. This Bash script loops around and makes a SSH connection to a host in a domain that I control, setting up a tunnel for port 3389 (RDP). From that domain, I can then remote desktop into the Windows system. Basically I can deploy this solution on any Windows machine on any network where outbound SSH is allowed, and have remote access to it. You might want to look at the "autossh" Cygwin package. It handles exactly this use case and can be registered as a Windows service without any non-Cygwin utilities. Hi David, thanks for bringing this to my attention. That seems to use something called cygrunsrv, which is what I should have used for that script (and will be sure to do upon the next opportunity of using it again). Just look at /usr/share/doc/autossh/README.Cygwin after you install the package for details about the service. I've been using this for years for the purpose you've described and it's been working great. I'm reading the documentation and basically my 25 line script has all the features, including exponential backoff for restarting a failed connection. I'm not terribly in favor of formal packages that can be replaced by a shell scripts that fit into an 80x25 window. Here it is: #!/bin/bash PATH=/bin:/usr/bin THISDIR=/cygdrive/C/Cygwin/.ssh DEST=@ sleep_exp=0 while true ; do time_before=$(date +%s) ssh -i $THISDIR/id_rsa -vv -R :3389:127.0.0.2:3389 \ -o UserKnownHostsFile=$THISDIR/known_hosts \ -o PasswordAuthentication=no \ -o ServerAliveInterval=60 \ -o ServerAliveCountMax=3 \ $DEST rdp 2> /.ssh/log time_now=$(date +%s) if [ $(( time_now - time_before )) -le 600 ] ; then sleep_exp=$(( sleep_exp >= 9 ? sleep_exp : sleep_exp + 1 )) else sleep_exp=0 fi sleep $(( ((1 << sleep_exp) + 15) / 16 )) done Why do we execute a command called "rdp" on the remote host? Because the home directory of the account that is used has the following shell script as its login shell: #!/bin/bash if [ $# -ne 2 ] || [ "$1" != "-c" ] ; then echo interactive login not permitted echo "$@" >> ~/.log exit 1 fi case "$2" in rdp ) while true ; do sleep 3600 ; done ;; * ) echo that command is not allowed exit 1 ;; esac This is necessary because the Windows machine has a password-unprotected private key that it uses to log in to this. The service automatically starts if the Windows is rebooted, without requiring any password. Anyone with access to the Windows machine (such as an IT admin) who finds this stuff could use that key to SSH to that account on that host. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Using ARM GNU GCC with Cygwin
Well then. This certainly turned out to be all sorts of interesting discussion. :) I for one also can say it's nice to have a cygwin environment over DOS if I'm forced to a CLI on Windows. Most of my days are spent on Linux -- but it looks like I have some legit CLI time coming on Windows and cygwin was my first go-to thought for that. It's already bad enough how many times I type 'ls -l' in DOS to get an error. HAhahaha. (two thumbs up) -Ben -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Using ARM GNU GCC with Cygwin
On 4/8/2020 1:50 PM, Kaz Kylheku via Cygwin wrote: On 2020-04-04 11:58, Åke Rehnman via Cygwin wrote: I have a major use case for Cygwin for providing remote access to Windows. Using a non-Cygwin utility called "RunAsService.EXE", I turned a Cygwin Bash script into a Windows service. This Bash script loops around and makes a SSH connection to a host in a domain that I control, setting up a tunnel for port 3389 (RDP). From that domain, I can then remote desktop into the Windows system. Basically I can deploy this solution on any Windows machine on any network where outbound SSH is allowed, and have remote access to it. You might want to look at the "autossh" Cygwin package. It handles exactly this use case and can be registered as a Windows service without any non-Cygwin utilities. Just look at /usr/share/doc/autossh/README.Cygwin after you install the package for details about the service. I've been using this for years for the purpose you've described and it's been working great. -- David Rothenberger daver...@acm.org QOTD: "Overweight is when you step on your dog's tail and it dies." -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Using ARM GNU GCC with Cygwin
On 2020-04-04 11:58, Åke Rehnman via Cygwin wrote: On 2020-04-04 16:32, Kaz Kylheku via Cygwin wrote: On 2020-04-04 02:00, Ben wrote: Is there something else I'm missing? That by cross-compiling for your targets on Cygwin instead of a real POSIX OS, you will something like double your compile times, if not more. Why would you involve Cygwin in a development activity whose target isn't POSIX on Windows. Most strange comment I have read... With your reasoning why bother with cygwin at all for any reason? There are excellent reasons, obviously: Firstly: to have a familiar POSIX environment available on Windows, for personal use, where Windows is dictated by a workplace. For instance, one use case of mine for dropping into Cygwin is to run ImageMagick's convert command to either convert a .pdf file into multiple .png files or vice versa. This is in the context of work e-mails (Outlook, Exchange, ...). I have a major use case for Cygwin for providing remote access to Windows. Using a non-Cygwin utility called "RunAsService.EXE", I turned a Cygwin Bash script into a Windows service. This Bash script loops around and makes a SSH connection to a host in a domain that I control, setting up a tunnel for port 3389 (RDP). From that domain, I can then remote desktop into the Windows system. Basically I can deploy this solution on any Windows machine on any network where outbound SSH is allowed, and have remote access to it. Secondly: to port stuff to Windows that has to run on Windows for reasons like the target users being tied to Windows, yet uses lots of POSIX API's. "A cross-compiling GNU toolchain" isn't an example of an application that must run on Windows. It's not shipped to users. The system/device being targeted by the cross-compiling is what is shipped to users. Why wouldn't you use the best possible environment for that, on a robust, fast OS. OP has explained that he's just curious to get that working, and there is certainly nothing wrong with that. I certainly don't want to dictate to him what he should find interesting and motivating; that was not the intent of my remark. I also must acknowledge the following: there may be a situation whereby the embedded system in question (quite stupidly, but out of your control) requires communication with Windows for some procedure like flashing part of the firmware or something (say over USB). The people responsible for that developed a utility which only runs on Windows. If you can build on Windows, then the whole workflow is easily streamlined, including the part where you have to kick off the FOOBAR.EXE to do that annoying step. It nicely runs on just one machine without any extra copying of images and whatnot. (Yes, I've dealt with stuff like that, but usually outside of the regular dev cycle. Like say for flashing an low-level bootloader not touched by regular rebuilds of the main image, or recovering a totally "bricked" unit and such.) -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] gdb-9.1-1 (TEST)
The following package has been updated in the Cygwin distribution: * gdb-9.1-1 The GNU debugger allows you to debug programs written in C, C++, and other languages, by executing them in a controlled fashion and printing their data. This is an update to a later upstream version: https://sourceware.org/pipermail/gdb-announce/2020/000122.html See the /usr/share/doc/gdb/NEWS file for a list of user-visible changes. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: fetchmail-6.4.3-1
The current upstream release of fetchmail is now available on Cygwin as the fetchmail-6.4.3-1 package. The upstream release changelog is here: https://sourceforge.net/projects/fetchmail/files/branch_6.4/ This release has been compiled with support for NTLM, GSSAPI and Kerberos5 authentication. Also, since this release now requires and uses OpenSSL v1.1.1, TLSv1.3 is now available. -- *** 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: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Mingw pkg-config not working
Hello, I would like to report that I updated to the latest release, I tried to do some tests and it really seems that it has resolved the issue on my side. Thank you very much for your support. Sincerely, Carlo Bramini. Il giorno lun 6 apr 2020 alle ore 18:44 Yaakov Selkowitz ha scritto: > > On Sun, 2020-04-05 at 15:51 +0200, Carlo B. via Cygwin wrote: > > I wanted to report that I received a reply on the issue that I had opened > > here: > > > > https://todo.sr.ht/~kaniini/pkgconf/10#comment-7894 > > Thanks for following up. > > > The report has been closed and I got this reply: > > > > "You should use a symlink instead of a wrapper script when using the > > personality feature." > > > > I hope that somebody has understood what he means (posix is not > > exactly my primary platform) and it could be useful for fixing the > > issue. > > Yes, that gave me the information I needed. There is actually code > within pkgconf to automatically load $PREFIX.personality when called as > $PREFIX-pkg-config. This requires a packaging change on our end, which > I'm incorporating into the latest release. > > > Il giorno gio 26 mar 2020 alle ore 14:07 Carlo B. > > ha scritto: > > > Hello, > > > I implemented the solution to this problem as a patch to > > > pkgconf.cygport as requested. > > > I attached small patch to this email, which resolved the troubles with > > > CMake and Meson. > > > I hope that you will find it useful and some developers will gently > > > apply the correction to fix the issue. > > > > > > Thank you very much for your time and your support. > > > Sincerely, > > > > > > Carlo Bramini. > > > > > > Il giorno sab 22 feb 2020 alle ore 18:47 Jon Turney > > > ha scritto: > > > > On 20/02/2020 11:06, Carlo B. wrote: > > > > [...] > > > > > x86_64-w64-mingw32-pkg-config are emulated with a shell script, for > > > > > example the one for i686 is: > > > > > > > > > > #!/bin/sh > > > > > exec pkgconf --personality=i686-w64-mingw32 $@ > > > > > > > > > > But while this solution mostly works when you exec it from the command > > > > > line, it makes impossible to detect the presence of the tool from > > > > > meson and cmake build systems. > > > > > If you try to do this on the bash prompt, you get: > > > > > > > > > > $ i686-w64-mingw32-pkg-config --version > > > > > pkgconf: --version specified with other options or module names, > > > > > assuming --modversion. > > > > > Please specify at least one package name on the command line. > > > > > > > > > > and this is exactly what happens with those build systems (and perhaps > > > > > others, I don't know): it tries to call pkg-config with "--version" > > > > > and it executes the above script that calls pkgconf. But sadly, the > > > > > presence of the "--personality" option makes the process to fail, > > > > > because the "--version" is currently allowed only when no other > > > > > options are added. > > > > > And, for this reason, meson and cmake fail the detection of the tool. > > > > > > > > > > I have also filed an issue here for pkgconf: > > > > > https://todo.sr.ht/~kaniini/pkgconf/10 > > > > > because the solution is actually to ignore the presence of the > > > > > "--personality" option when the "--version" is written, but > > > > > unfortunately I have not received any feedback. > > > > > > > > > > So, I'm also writing here, with the hope that you could find a > > > > > solution. > > > > [...] > > > > > > > > Thanks for reporting this issue. > > > > > > > > I guess the alternative to fixing pkgconf would be to modify those > > > > wrapper scripts to detect when the parameters are just '--version' (or > > > > equivalent) and not use --personality in that case? > > > > > > > > These wrapper scripts are specific to cygwin (generated by the cygport, > > > > see [1]) > > > > > > > > It's possible other distros have more sophisticated wrapper scripts, > > > > which avoid this problem? > > > > > > > > If you do write or discover some improved wrapper scripts, a patch to > > > > [1] to update them would be appreciated. > > > > > > > > [1] > > > > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/pkgconf.git;a=blob;f=pkgconf.cygport#l84 > > -- > Yaakov > > > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation:https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: OpenSSL
> Am 08.04.2020 um 11:30 schrieb Tommie King: > > Hey, sorry if this is the wrong place. > > Hi Tommie, > right place > > > But im struggling to see how I can upgrade openssl >1.1.1d > > > > Compliance checks state that we must have a more up to date version, I > > know that it exists (1.1.1f) > > that was released just 2 weeks ago. [Allen Hewes] Fedora has updated their bits (Cygwin's version uses some of Fedora's packaging): https://src.fedoraproject.org/rpms/openssl/c/5004ccfb250b6b8e6e1ac40ee91433090dc19366?branch=master > > > But I can only seem to upgrade to 1.1.1 in Cygwin - is there a new > > upgrade package for Cygwin/Openssl coming in the near future? > > https://cygwin.com/packages/summary/openssl.html > last available version is 1.1.1d > > Next version when the maintainer has time to do so. > [Allen Hewes] ...or build it yourself (learn cygport and the associated stuffs to get it installed via setup-x86_64.exe, this is non-trivial depending on your skills (and time 😉)...): $ uname -a CYGWIN_NT-10.0 FOUREYES 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin $ cygcheck -c openssl Cygwin Package Information Package VersionStatus openssl 1.1.1f-1 OK This also allows one to change OpenSSL to suit their specific needs (maybe you need/want FIPS?): $ openssl version OpenSSL 1.1.1f FIPS 31 Mar 2020 /allen Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or documents linked to this email, are intended for the addressee and may contain information that is privileged, confidential, proprietary, or otherwise protected by law. Any dissemination, distribution, or copying is prohibited. This notice serves as a confidentiality marking for the purpose of any confidentiality or nondisclosure agreement. If you have received this communication in error, please contact the original sender. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Sv: Sv: open descriptor to named pipes sometimes fail
On 4/8/2020 8:53 AM, Ken Brown via Cygwin wrote:
On 4/8/2020 4:52 AM, sten.kristian.ivars...@gmail.com wrote:
On 4/7/2020 2:38 PM, sten.kristian.ivars...@gmail.com wrote:
On 4/7/2020 11:10 AM, Kristian Ivarsson via Cygwin wrote:
Opening a (second) descriptor for (blocking) write sometimes fail
The provided test case sometimes succeed, but quite often fail with
ENOENT (in various indexes)
I haven't dug deeper to find the underlaying cause yet
Have anyone experienced this before ?
I can't reproduce this on my system. I changed 1000 to 1 and
then ran your test case 10 times, and it never failed. I tested both
cygwin-3.1.4 and the HEAD of the topic/fifo branch (which I recently
force-pushed in case you want to try it).
Can you run your test under strace and see if that provides a clue?
I'm running things on a few year old laptop, perhaps with less muscles
;-)
With strace it was harder to reproduce, but I could reproduce it (and
it happen to be the first iteration this time)
Does this help?
--- a/winsup/cygwin/fhandler_fifo.cc
+++ b/winsup/cygwin/fhandler_fifo.cc
@@ -624,7 +624,8 @@ fhandler_fifo::open (int flags, mode_t)
else
goto success;
}
- else if (STATUS_PIPE_NO_INSTANCE_AVAILABLE (status))
+ else if (STATUS_PIPE_NO_INSTANCE_AVAILABLE (status)
+ | status == STATUS_OBJECT_NAME_NOT_FOUND)
continue;
else
{
Did you mean to use the bit-or-operator or the or-operator ?
The or-operator. Thanks for catching that.
I did
...
else if (STATUS_PIPE_NO_INSTANCE_AVAILABLE (status) || status ==
STATUS_OBJECT_NAME_NOT_FOUND)
...
and with that change I cannot reproduce the error in the test-program
Great. I'll push it to the topic/fifo branch. For the record, that patch was
motivated by your strace output, which showed NtOpenFile failing with status
0xC034, which is STATUS_OBJECT_NAME_NOT_FOUND.
This was not a well-thought-out change. It creates a drastic slow-down. I'll
have to find a better solution.
Ken
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Linux compiling in kernel
On Wed, 2020-04-08 at 15:18 +0530, vishnu via Cygwin wrote: > I have installed cygwin. > I am trying to compile linux kernel.It is for x86 platform. > But When I give below command: > #make > CC scripts/mod/empty.o > cc1: error: code model kernel does not support PIC mode > make[1]: *** [scripts/Makefile.build:268: scripts/mod/empty.o] Error 1 > make: *** [Makefile:1116: prepare0] Error 2 > > This error iam facing. > Can you please help me. > > Your help is highly appreciated. https://sourceware.org/legacy-ml/cygwin/2012-06/msg00221.html -- Yaakov -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Donation to cygwin.com
Hi, I'm Dean Chester from CoolTechzone. We are interested in donating to your website. What's the donation for being mentioned with a link on your homepage? *Regards,* *Dean Chester* *CEO, Cyber Expert* *CoolTechZone* -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Sv: Sv: open descriptor to named pipes sometimes fail
On 4/8/2020 4:52 AM, sten.kristian.ivars...@gmail.com wrote:
On 4/7/2020 2:38 PM, sten.kristian.ivars...@gmail.com wrote:
On 4/7/2020 11:10 AM, Kristian Ivarsson via Cygwin wrote:
Opening a (second) descriptor for (blocking) write sometimes fail
The provided test case sometimes succeed, but quite often fail with
ENOENT (in various indexes)
I haven't dug deeper to find the underlaying cause yet
Have anyone experienced this before ?
I can't reproduce this on my system. I changed 1000 to 1 and
then ran your test case 10 times, and it never failed. I tested both
cygwin-3.1.4 and the HEAD of the topic/fifo branch (which I recently
force-pushed in case you want to try it).
Can you run your test under strace and see if that provides a clue?
I'm running things on a few year old laptop, perhaps with less muscles
;-)
With strace it was harder to reproduce, but I could reproduce it (and
it happen to be the first iteration this time)
Does this help?
--- a/winsup/cygwin/fhandler_fifo.cc
+++ b/winsup/cygwin/fhandler_fifo.cc
@@ -624,7 +624,8 @@ fhandler_fifo::open (int flags, mode_t)
else
goto success;
}
- else if (STATUS_PIPE_NO_INSTANCE_AVAILABLE (status))
+ else if (STATUS_PIPE_NO_INSTANCE_AVAILABLE (status)
+ | status == STATUS_OBJECT_NAME_NOT_FOUND)
continue;
else
{
Did you mean to use the bit-or-operator or the or-operator ?
The or-operator. Thanks for catching that.
I did
...
else if (STATUS_PIPE_NO_INSTANCE_AVAILABLE (status) || status ==
STATUS_OBJECT_NAME_NOT_FOUND)
...
and with that change I cannot reproduce the error in the test-program
Great. I'll push it to the topic/fifo branch. For the record, that patch was
motivated by your strace output, which showed NtOpenFile failing with status
0xC034, which is STATUS_OBJECT_NAME_NOT_FOUND.
We (with the open-source-application) do bump into some other issues later
in the chanin, but I haven't investigated what the issues are yet (lack of
time)
>
I'm a little confused why this "issue"/"report" didn't end up in the
cygwin-mailing list and why it became us having a private conversation ?
That was unintentional. I've added the list back to the Cc.
We're grateful that you're taking your time to look into this. Do you have
any clue of what the chances are to get these fixes (topic/fifo) into the
master branch and finally into an official release (or at least a snap-shot)
?
It shouldn't be too much longer. I'll regret making this prediction, but I'd
guess that the branch will be ready for wider testing within a few weeks.
Ken
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: OpenSSL
Am 08.04.2020 um 11:30 schrieb Tommie King: Hey, sorry if this is the wrong place. Hi Tommie, right place But im struggling to see how I can upgrade openssl >1.1.1d Compliance checks state that we must have a more up to date version, I know that it exists (1.1.1f) that was released just 2 weeks ago. But I can only seem to upgrade to 1.1.1 in Cygwin - is there a new upgrade package for Cygwin/Openssl coming in the near future? https://cygwin.com/packages/summary/openssl.html last available version is 1.1.1d Next version when the maintainer has time to do so. Thanks Tommie King -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Linux compiling in kernel
Hi Team, I have installed cygwin. I am trying to compile linux kernel.It is for x86 platform. But When I give below command: #make CC scripts/mod/empty.o cc1: error: code model kernel does not support PIC mode make[1]: *** [scripts/Makefile.build:268: scripts/mod/empty.o] Error 1 make: *** [Makefile:1116: prepare0] Error 2 This error iam facing. Can you please help me. Your help is highly appreciated. Thank you, Vishnu -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
OpenSSL
Hey, sorry if this is the wrong place. But im struggling to see how I can upgrade openssl >1.1.1d Compliance checks state that we must have a more up to date version, I know that it exists (1.1.1f) But I can only seem to upgrade to 1.1.1 in Cygwin - is there a new upgrade package for Cygwin/Openssl coming in the near future? Thanks Tommie King -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Dropping 32 bit Cygwin? (was Re: segfault on 32bit)
Hi Corinna, If I'm forced to abandon Windows, the next logical option for me is to use ReactOS, in order to use Cygwin for work. While it is usable as it is, right now it only has 32 bit, and 64 bit is still a long way to go. This is one primary reason that I believe Cygwin should keep the 32bit version. Also, as I personally experienced once, the 64bit version does not work properly and I'm not sure why. It could be the antivirus that was installed by my company. But, I can quickly continue my work after I install a 32bit version, and the issue is not there. So, having 32bit as a fallback is really helpful in that situation. Thank you. On Wed, Apr 8, 2020 at 4:45 PM Corinna Vinschen wrote: > On Apr 8 10:34, Corinna Vinschen wrote: > > Right. This looks like a fork problem. It's 32 bit, so we have to > > expect fork errors more often. > > > > Given how much the distro has grown, and given that the number of 32 bit > > systems is constantly shrinking, we should really start to think about > > dropping 32 bit support. > > > > Most users these days use 64 bit systems. Some use 32 bit Cygwin on 64 > > bit systems, which doesn't really make sense, except, maybe, to build 32 > > bit packages. These users can easily switch to 64 bit Cygwin. > > > > The access statistics indicate that real 32 bit systems only make less > > than 2% of installed systems. It's a lot of hassle to keep 32 bit > > Cygwin running for only a minor installation base. > > > > I'm not saying that we switch off 32 bit support right now, but maybe > > 2020 should be the last year of 32 bit support. > > Oh, btw., time_t on 32 bit Cygwin is only 32 bit wide, so the end is > near: 2038-01-19 03:14:07 UTC. > > > Corinna > > -- > Corinna Vinschen > Cygwin Maintainer > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation:https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple > -- Sharuzzaman Ahmat Raslan -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Dropping 32 bit Cygwin? (was Re: segfault on 32bit)
On Apr 8 10:34, Corinna Vinschen wrote: > Right. This looks like a fork problem. It's 32 bit, so we have to > expect fork errors more often. > > Given how much the distro has grown, and given that the number of 32 bit > systems is constantly shrinking, we should really start to think about > dropping 32 bit support. > > Most users these days use 64 bit systems. Some use 32 bit Cygwin on 64 > bit systems, which doesn't really make sense, except, maybe, to build 32 > bit packages. These users can easily switch to 64 bit Cygwin. > > The access statistics indicate that real 32 bit systems only make less > than 2% of installed systems. It's a lot of hassle to keep 32 bit > Cygwin running for only a minor installation base. > > I'm not saying that we switch off 32 bit support right now, but maybe > 2020 should be the last year of 32 bit support. Oh, btw., time_t on 32 bit Cygwin is only 32 bit wide, so the end is near: 2038-01-19 03:14:07 UTC. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Dropping 32 bit Cygwin? (was Re: segfault on 32bit)
On Apr 7 22:27, Csaba Ráduly via Cygwin wrote: > On 07/04/2020 19:33, Marco Atzeri via Cygwin wrote: > > while trying to build the 32bit version on python, > > I hit this never seen before issue: > > > > checking for %zd printf() format support... make: *** No targets > > specified and no makefile found. Stop. > > *** ERROR: make failed > > 4 [main] sh 18479 D:\cygwin32\bin\sh.exe: *** fatal error in > > forked process - WFSO timed out after longjmp > > 4 [main] sh 18479 D:\cygwin32\bin\sh.exe: *** fatal error in forked > > proces > > s - WFSO timed out after longjmp > > 72365 [main] sh 18479 cygwin_exception::open_stackdumpfile: Dumping > > stack trac > > e to sh.exe.stackdump > > 72365 [main] sh 18479 cygwin_exception::open_stackdumpfile: Dumping > > stack trac > > e to sh.exe.stackdump > > > > > > $ uname -svr > > CYGWIN_NT-10.0-WOW 3.1.4(0.340/5/3) 2020-02-19 08:45 > > > > what is a WFSO ? > > WaitForSingleObject, presumably. Right. This looks like a fork problem. It's 32 bit, so we have to expect fork errors more often. Given how much the distro has grown, and given that the number of 32 bit systems is constantly shrinking, we should really start to think about dropping 32 bit support. Most users these days use 64 bit systems. Some use 32 bit Cygwin on 64 bit systems, which doesn't really make sense, except, maybe, to build 32 bit packages. These users can easily switch to 64 bit Cygwin. The access statistics indicate that real 32 bit systems only make less than 2% of installed systems. It's a lot of hassle to keep 32 bit Cygwin running for only a minor installation base. I'm not saying that we switch off 32 bit support right now, but maybe 2020 should be the last year of 32 bit support. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
