RE: [ITP] onc-rpc-headers-20140129-1
Hello! Yes, this is where I got stuck before, when I tried to modernize the RPC NFS packages. We need to port rpcbind to cygwin, then modify the nfs server. I have a partial port of rpcbind...it compiles (or did), but doesn't run. Here it runs quite fine. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
[ITP] onc-rpc-devel-2_19_20140211-1
Hello! This is me again, and this is my promised RPC package. Folder URL: https://www.dropbox.com/sh/s95jz1ql5xs8yx7/8mhUDlI_Kg I have updated the whole thing using recent source code. Translations included. I hope you'll like the result. One small question: how to specify in setup.hint that this package replaces old rpcgen and sunrpc ? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia setup.hint Description: Binary data
Re: [ITP] onc-rpc-devel-2_19_20140211-1
On 2/12/2014 7:45 AM, Pavel Fedin wrote: This is me again, and this is my promised RPC package. Folder URL: https://www.dropbox.com/sh/s95jz1ql5xs8yx7/8mhUDlI_Kg I have updated the whole thing using recent source code. Translations included. I hope you'll like the result. One small question: how to specify in setup.hint that this package replaces old rpcgen and sunrpc ? Actually, you don't do that in your setup.hint. Instead, the maintainer(s) of the old rpcgen and sunrpc packages publish new (empty) versions of them, and in the new setup.hints for those, mark them as follows: requires: one-rpc-devel category: _obsolete Give me a day or two to validate your package, and create the new versions of the old packages, and then we'll coordinate a simultaneous upload. -- Chuck
RE: [ITP] onc-rpc-devel-2_19_20140211-1
Hello! Give me a day or two to validate your package, and create the new versions of the old packages, and then we'll coordinate a simultaneous upload. No, i386 should wait for now. If we remove 'sunrpc', we remove portmapper, on which nfs-server depends. i386 can be changed only after both rpcbind and nfs-server update are completed. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
Re: Newbie Alias and Profile questions
OK, I got it working ... I have my home in an directory other that what Cygwin defaults because other software run needs I thought my files were being overwritten ... but no - I was modifying the wrong files. After I found the correct files and modified the .bash_profile everything was fine. I was not aware of this .bash_profile and I was not aware of the source command. On the versions of Unix/Linux that I have used I would always do a .profile to execute the commands in it when I made changes. So again I was making changes and the shell was not aware of the changes. Hey, I've been using Cygwin for like 2 weeks ,,, On 2/10/2014 9:13 PM, Mike Rushton wrote: Well let me work at it tomorrow. I know how to do this on other unix systems, just that Cygwin is not acting as I am used too. I have done things like this on some versions of RHEL, UnixWare, Xenix, MKS Tookit. I guess I have to keep reading the Documentation and trying things. ( and no more use of the term Newbie :-) ) On 2/10/2014 8:26 PM, Larry Hall (Cygwin) wrote: On 2/10/2014 8:15 PM, Mike Rushton wrote: Can some one give me some hints about this ? I read the documentation and can't figure this out. I am trying to put an alias in a .bashrc alias clear='printf \033c' But what .bashrc do I put this in ? in /ect/skel or the one my user directory. I put this code in and it seems to get overwritten. I don't understand what I am doing wrong. Overwritten? By what? What's your home directory? It is a minor thing that i can't clear the screen, but i want to work at this and try to fix this. OK but 'clear' will do what you want. Then I want to add a script to my profile. but what one the .profile or .bash_profile ? Unless you want it available to all users and other shells, put it in your .bash_profile. Other that these problems, I am converting my Korn shell scripts to bash under Cygwin and it is going pretty good so far. FYI, at least the last 2 questions above are general UNIX/Linux questions. You should consult a good UNIX/Linux resource for some basic user tutorials and guides. -- 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: get rid of getpwent? (Was: cygwin-1.7.28 getpwent header declaration changes ?)
On Feb 11 19:06, Eric Blake wrote: On 02/11/2014 05:06 PM, Warren Young wrote: On 2/11/2014 16:25, David Stacey wrote: getpwent() is called in three different places. To those of you who have investigated these code paths: do any of them look like they couldn't be replaced by getpwnam() or other calls that would let cygwin1.dll do single-record AD/SAM lookups, rather than whole-table/tree scans? That is, do any of these programs really need to visit every record in /etc/passwd? libreadline wants to know how to tab-complete ~foo; to do that, it has to find all usernames beginning with foo. How would you do that without visiting every single record? This seems to be the major usage of getpwent these days. The question is, how bad is it if only a handful entries, or even only a single one (of oneself) show up? Either way, implementing a full getpwent requires to return the local users, the users of the primary domain, and the users of all trusted domains. I know of domains with 200K users and there are probably bigger ones. How long should a search take when a user presses TAB after the ~? And then, shall the process running the getpwent actually cache all of them? This seems really excessive. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpcPzVinfHBS.pgp Description: PGP signature
Re: snapshots dated 20140210 fail
On Feb 11 14:41, Warren Young wrote: On 2/11/2014 02:20, Corinna Vinschen wrote: Can you please both test the snapshot DLLs from today? Both versions, 32 and 64 bit, work fine for me on Windows 8.1. Sunshine and butterflies: $ uname -a CYGWIN_NT-6.3-WOW64 amanita 1.7.29s(0.271/5/3) 20140211 18:42:13 i686 Cygwin Insert a light spring melody here Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpWGD38tC1pT.pgp Description: PGP signature
RE: Is There A Way to Update ADB?
Thanks, Balaji! I know what to do now. Thanks also, Christopher. -- 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: get rid of getpwent? (Was: cygwin-1.7.28 getpwent header declaration changes ?)
Greetings, Corinna Vinschen! Either way, implementing a full getpwent requires to return the local users, the users of the primary domain, and the users of all trusted domains. I know of domains with 200K users and there are probably bigger ones. How long should a search take when a user presses TAB after the ~? And then, shall the process running the getpwent actually cache all of them? This seems really excessive. IMO, such practice should be actually discouraged. I mean, listing ALL users of ALL... well, you got it. For the reasons you mentioned above - the possible results of such operation are largely unpredictable. -- WBR, Andrey Repin (anrdae...@yandex.ru) 12.02.2014, 15:49 Sorry for my terrible english... -- 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: Newbie Alias and Profile questions
Greetings, Mike Rushton! Please don't http://cygwin.com/acronyms/#TOFU OK, I got it working ... I have my home in an directory other that what Cygwin defaults because other software run needs I thought my files were being overwritten ... but no - I was modifying the wrong files. After I found the correct files and modified the .bash_profile everything was fine. I was not aware of this .bash_profile and I was not aware of the source command. On the versions of Unix/Linux that I have used I would always do a .profile to execute the commands in it when I made changes. You've been pointed to the bash man page. It is all explained there, English on black. So again I was making changes and the shell was not aware of the changes. Hey, I've been using Cygwin for like 2 weeks ,,, As has been said already, this is NOT a Cygwin question. -- WBR, Andrey Repin (anrdae...@yandex.ru) 12.02.2014, 15:52 Sorry for my terrible english... -- 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: snapshots dated 20140210 fail
On 2014-02-11 21:39, Denis Excoffier wrote: On 2014-02-11 10:20, Corinna Vinschen wrote: On Feb 10 16:09, Warren Young wrote: On 2/10/2014 15:53, Denis Excoffier wrote: I can see another one, dated 22:17:21 UTC. Same problem as for the 3rd and 4th: windows complaint that this is not a windows image. Confirmed. Can you please both test the snapshot DLLs from today? Both versions, 32 and 64 bit, work fine for me on Windows 8.1. Tested the snapshot (of today) dated 18:45:46 UTC (18:42:13 inside), and it seems to work perfectly. I’ve also successfully built it from sources. Oops, i believe i was too enthusiastic. In fact i tested on XP SP3 only. But on Seven, it does not seem to work (/usr/bin/id still dumps core). Denis Excoffier. -- 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: snapshots dated 20140210 fail
On Feb 12 13:47, Denis Excoffier wrote: On 2014-02-11 21:39, Denis Excoffier wrote: On 2014-02-11 10:20, Corinna Vinschen wrote: On Feb 10 16:09, Warren Young wrote: On 2/10/2014 15:53, Denis Excoffier wrote: I can see another one, dated 22:17:21 UTC. Same problem as for the 3rd and 4th: windows complaint that this is not a windows image. Confirmed. Can you please both test the snapshot DLLs from today? Both versions, 32 and 64 bit, work fine for me on Windows 8.1. Tested the snapshot (of today) dated 18:45:46 UTC (18:42:13 inside), and it seems to work perfectly. I’ve also successfully built it from sources. Oops, i believe i was too enthusiastic. In fact i tested on XP SP3 only. But on Seven, it does not seem to work (/usr/bin/id still dumps core). That's not very helpful, unfortunately. I'm testing this stuff in parallel on four different machines running three different OS versions, on 32 and 64 bit machines, and I can't reproduce any crash, now that I fixed my braindead type in the debug output statement. I need *details*. Stackdumps, straces, GDB session results, ... patches. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpJ5xyUkaIuE.pgp Description: PGP signature
Re: Clearing the buffer after quitting LESS, MAN, VIM etc.
Christopher Faylor cgf-use-the-mailinglist-please at cygwin.com writes: You're apparently not using a snapshot. cgf Hi there! I have discovered one more bug, which seems to be related: I'm working with CLI having long scrollback buffer. I need to read something a couple of pages back, so I scroll back in the buffer. Then I clear the screen with CTRL + L. Screen is already cleared, but only the visible screen in the middle of scrollback buffer. When content fulfills the whole screen and it starts to scroll, the new output is mixed with previous buffer content. Also scrollback buffer is now messed. I think, that clearing of the screen with CTRL + L should work as in the Linux terminal (e.g. Gnome Terminal). When I press CTRL + L in the middle of scrollback buffer, it just jumps to the end of scrollback buffer. Nothing is really deleted. This way, the whole scrollback buffer is preserved and screen is also cleared. So, clearing the screen doesn't clear anything in the fact. It just scrolls the content up until the whole screen is blank and prompt is on the first line. I think, that these bugs result from different philosophy of working with buffer from the Linux terminal. I could live with that, I just have to clear the screen on the end of scrollback buffer only. But messing of scrollback buffer, when I quit e.g. LESS as I described in my previous post, is really pain. The buffer is messed so many times, how much prompts are on the current screen. When I scroll one page back, screen is repainted with buffer only from bottom to the most bottom prompt (that means only few lines could be repainted, for example), where the most bottom prompt is repainted too. So I scroll one more page back and it repeats, but with another most bottom prompt. Until all prompts on the current screen are repainted. Then it starts to scroll properly. Thank you and have a nice day. -- Dawid Ferenczy http://ferenczy.cz -- 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: Clearing the buffer after quitting LESS, MAN, VIM etc.
On 2/12/2014 8:33 AM, Dawid Ferenczy wrote: Christopher Faylor cgf-use-the-mailinglist-please at cygwin.com writes: You're apparently not using a snapshot. cgf Hi there! I have discovered one more bug, which seems to be related: ... And which snapshot are you using? http://cygwin.com/snapshots/ -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: get rid of getpwent? (Was: cygwin-1.7.28 getpwent header declaration changes ?)
On Wed, 12 Feb 2014, Corinna Vinschen wrote: On Feb 11 19:06, Eric Blake wrote: On 02/11/2014 05:06 PM, Warren Young wrote: On 2/11/2014 16:25, David Stacey wrote: getpwent() is called in three different places. To those of you who have investigated these code paths: do any of them look like they couldn't be replaced by getpwnam() or other calls that would let cygwin1.dll do single-record AD/SAM lookups, rather than whole-table/tree scans? That is, do any of these programs really need to visit every record in /etc/passwd? libreadline wants to know how to tab-complete ~foo; to do that, it has to find all usernames beginning with foo. How would you do that without visiting every single record? This seems to be the major usage of getpwent these days. The question is, how bad is it if only a handful entries, or even only a single one (of oneself) show up? Either way, implementing a full getpwent requires to return the local users, the users of the primary domain, and the users of all trusted domains. I know of domains with 200K users and there are probably bigger ones. How long should a search take when a user presses TAB after the ~? And then, shall the process running the getpwent actually cache all of them? This seems really excessive. Not only is it excessive, it's a massive security hole. ...I don't know why the present crop of geniuses don't know one of the most fundamental rules of security: don't give up usernames. (Yet, they do it all the time.) I vote get rid of the damned thing - not that my vote counts or that this is the place for it anyway! Richard -- 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: g77 on cygwin64
Thank-you to those that responded with suggestions involving my fortran issues. Fixing the code is not something I am going to pursue since the source code was written by several different colleagues and is spread out amongst many .f files. My colleagues have no interest in fixing it since they have g77 on their unix machines, and to them, it isn't broken. The strange thing is that gfortran does compile the code, but once compiled, the executables have strange behavior mainly involving problems reading in data files. So it is not clear to me exactly what needs to be updated in the code. I have tried to compile gcc 3.4.6 from source with no luck, but I am not so good with compiler flags and makefiles. I will give it a go again, but I am not optimistic. So, to avoid further mean comments about my course of action being stupid, I will sign off. -Scott On 2/12/2014 2:31 AM, Arjen Markus wrote: I agree with Andrey - could you give us examples of code fragments that are not accepted by gfortran but are by g77? Regards, Arjen 2014-02-12 8:14 GMT+01:00 Andrey Repin anrdae...@yandex.ru: Greetings, Scott T. Marshall! Would it be very difficult to take the old g77 source and recompile it for cygwin64? Has anyone successfully done this before? It would certainly be easier to fix you code to compile with standards-conformant compiler. Because every other course of action seems counterproductive, if not plain stupid. -- WBR, Andrey Repin (anrdae...@yandex.ru) 12.02.2014, 11:13 Sorry for my terrible english... -- 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 -- 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: g77 on cygwin64
On Wed, Feb 12, 2014 at 11:14:51AM +0400, Andrey Repin wrote: Greetings, Scott T. Marshall! Would it be very difficult to take the old g77 source and recompile it for cygwin64? Has anyone successfully done this before? It would certainly be easier to fix you code to compile with standards-conformant compiler. Because every other course of action seems counterproductive, if not plain stupid. Come on, Andrey. There is no reason to use the word stupid here. You could have just stopped with counterproductive and not sounded so insulting. cgf -- 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: get rid of getpwent? (Was: cygwin-1.7.28 getpwent header declaration changes ?)
On 2/12/2014 4:08 AM, Corinna Vinschen wrote: On Feb 11 19:06, Eric Blake wrote: On 02/11/2014 05:06 PM, Warren Young wrote: On 2/11/2014 16:25, David Stacey wrote: getpwent() is called in three different places. To those of you who have investigated these code paths: do any of them look like they couldn't be replaced by getpwnam() or other calls that would let cygwin1.dll do single-record AD/SAM lookups, rather than whole-table/tree scans? That is, do any of these programs really need to visit every record in /etc/passwd? libreadline wants to know how to tab-complete ~foo; to do that, it has to find all usernames beginning with foo. How would you do that without visiting every single record? This seems to be the major usage of getpwent these days. The question is, how bad is it if only a handful entries, or even only a single one (of oneself) show up? Either way, implementing a full getpwent requires to return the local users, the users of the primary domain, and the users of all trusted domains. I know of domains with 200K users and there are probably bigger ones. How long should a search take when a user presses TAB after the ~? And then, shall the process running the getpwent actually cache all of them? This seems really excessive. What about the following compromise: If /etc/passwd exists, then getpwent behaves as it does currently. Otherwise, it returns a handful of entries, or possibly just the current user. This gives users a choice. If tab-completion in this situation is important to them, they can keep their /etc/passwd file. Ken -- 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: get rid of getpwent? (Was: cygwin-1.7.28 getpwent header declaration changes ?)
On Wed, 12 Feb 2014, Ken Brown wrote: On 2/12/2014 4:08 AM, Corinna Vinschen wrote: On Feb 11 19:06, Eric Blake wrote: On 02/11/2014 05:06 PM, Warren Young wrote: On 2/11/2014 16:25, David Stacey wrote: getpwent() is called in three different places. To those of you who have investigated these code paths: do any of them look like they couldn't be replaced by getpwnam() or other calls that would let cygwin1.dll do single-record AD/SAM lookups, rather than whole-table/tree scans? That is, do any of these programs really need to visit every record in /etc/passwd? libreadline wants to know how to tab-complete ~foo; to do that, it has to find all usernames beginning with foo. How would you do that without visiting every single record? This seems to be the major usage of getpwent these days. The question is, how bad is it if only a handful entries, or even only a single one (of oneself) show up? Either way, implementing a full getpwent requires to return the local users, the users of the primary domain, and the users of all trusted domains. I know of domains with 200K users and there are probably bigger ones. How long should a search take when a user presses TAB after the ~? And then, shall the process running the getpwent actually cache all of them? This seems really excessive. What about the following compromise: If /etc/passwd exists, then getpwent behaves as it does currently. Otherwise, it returns a handful of entries, or possibly just the current user. This gives users a choice. If tab-completion in this situation is important to them, they can keep their /etc/passwd file. Works for me! And I'd vote just the current user in lieu of a handful because even a handful has a huge overhead associated with it. Richard -- 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: get rid of getpwent? (Was: cygwin-1.7.28 getpwent header declaration changes ?)
Greetings, Ken Brown! What about the following compromise: If /etc/passwd exists, then getpwent behaves as it does currently. Otherwise, it returns a handful of entries, or possibly just the current user. This gives users a choice. If tab-completion in this situation is important to them, they can keep their /etc/passwd file. Makes sense. You get your current user name substituted in all cases, if you want more - you fill in the list of the names you want to see. -- WBR, Andrey Repin (anrdae...@yandex.ru) 12.02.2014, 21:03 Sorry for my terrible english... -- 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: g77 on cygwin64
On 12/02/2014 16:07, Scott T. Marshall wrote: Thank-you to those that responded with suggestions involving my fortran issues. Fixing the code is not something I am going to pursue since the source code was written by several different colleagues and is spread out amongst many .f files. My colleagues have no interest in fixing it since they have g77 on their unix machines, and to them, it isn't broken. The strange thing is that gfortran does compile the code, but once compiled, the executables have strange behavior mainly involving problems reading in data files. So it is not clear to me exactly what needs to be updated in the code. I have tried to compile gcc 3.4.6 from source with no luck, but I am not so good with compiler flags and makefiles. I will give it a go again, but I am not optimistic. So, to avoid further mean comments about my course of action being stupid, I will sign off. -Scott Hi Scott As he wrote Sorry for my terrible english..., I assume it was not intentional offensive. Coming back to your issue, it is really curious that gfortran compiles the code but behaves wrongly, I was expecting it rejects the code if not in line with latest standard. I saw rejected code with lapack some time ago, and the correction was trivial. But compiling and not working is a serious gfortran bug. Have you a short test case ? 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: g77 on cygwin64
Greetings, Scott T. Marshall! Please don't http://cygwin.com/acronyms/#TOFU Thank-you to those that responded with suggestions involving my fortran issues. Fixing the code is not something I am going to pursue since the source code was written by several different colleagues and is spread out amongst many .f files. My colleagues have no interest in fixing it since they have g77 on their unix machines, and to them, it isn't broken. Our logs show nothing, server runs fine. If only you knew, how many times I've heard this argument... The strange thing is that gfortran does compile the code, but once compiled, the executables have strange behavior mainly involving problems reading in data files. So it is not clear to me exactly what needs to be updated in the code. And this is finally the information, that we can work with. My wild guess is that your colleagues making certain assumptions about files, that not always true on other systems. I.e. opening a file in text mode, and then treating it's data as binary safe, quite predictable, prone to fail (not actual opening, but reading and writing operations on it) on systems with different line endings. I have tried to compile gcc 3.4.6 from source with no luck, but I am not so good with compiler flags and makefiles. I will give it a go again, but I am not optimistic. So, to avoid further mean comments about my course of action being stupid, I will sign off. I beg for forgiveness. Was merely trying to save you some time. Perhaps, trying too hard... -- WBR, Andrey Repin (anrdae...@yandex.ru) 12.02.2014, 21:10 Sorry for my terrible english... -- 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: g77 on cygwin64
Marco Atzeri wrote: On 12/02/2014 16:07, Scott T. Marshall wrote: Thank-you to those that responded with suggestions involving my fortran issues. Fixing the code is not something I am going to pursue since the source code was written by several different colleagues and is spread out amongst many .f files. My colleagues have no interest in fixing it since they have g77 on their unix machines, and to them, it isn't broken. The strange thing is that gfortran does compile the code, but once compiled, the executables have strange behavior mainly involving problems reading in data files. So it is not clear to me exactly what needs to be updated in the code. I have tried to compile gcc 3.4.6 from source with no luck, but I am not so good with compiler flags and makefiles. I will give it a go again, but I am not optimistic. So, to avoid further mean comments about my course of action being stupid, I will sign off. -Scott Hi Scott As he wrote Sorry for my terrible english..., I assume it was not intentional offensive. Coming back to your issue, it is really curious that gfortran compiles the code but behaves wrongly, I was expecting it rejects the code if not in line with latest standard. I saw rejected code with lapack some time ago, and the correction was trivial. But compiling and not working is a serious gfortran bug. Have you a short test case ? 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 Coming back to your issue, it is really curious that gfortran compiles the code but behaves wrongly, I was expecting it rejects the code if not in line with latest standard. This happens on some of my code as well and is in many ways a far worse issue to deal with. Some of my code compiles and runs, but the floating point answers to many of the calculations are wrong. This makes the issue(s) very difficult to run down (and also makes me stick with gcc3 like the posters colleagues). LMH -- 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: g77 on cygwin64
On Wed, Feb 12, 2014 at 12:16 PM, Andrey Repin wrote: The strange thing is that gfortran does compile the code, but once compiled, the executables have strange behavior mainly involving problems reading in data files. ... And this is finally the information, that we can work with. My wild guess is that your colleagues making certain assumptions about files, that not always true on other systems. I.e. opening a file in text mode, and then treating [its] data as binary ... Since the problem occurs going from 32-bit to 64-bit Cygwin, it sounds to me like all-the-world's-a-VAX syndrome. I bet there are places where it reads from files and assumes that if it reads N words into integers, that is N 32-bit quantities, or something like that. I haven't written any Fortran since the 1980s, but I bet there are types that have changed size due to the switch to 64-bit and that results in reading incorrect values from files, including reading some of them from the wrong file offsets, and hitting end-of-file at a different point. Are there any switches to gfortran that control this? I took a brief look, and the only thing I saw was the -finteger-4-integer-8 option and friends, but that sounds like going the opposite direction you want to go, and the -ff2c option that generates C code. You could run the code through g77 on 32-bit, gfortran on 64-bit, and compare the C code generated for the file handling. But I suspect that's more hassle than you want to get into; it doesn't sound like fun to me. Good luck. -- 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
Status of Xemacs on cygwin64. Is help needed?
I don't have a lot of free time but I miss my Xemacs. If I can make a difference I would like to volunteer and help release this package but I am a total cygwin package noob.
Re: g77 on cygwin64
On Wed, 12 Feb 2014, David Conrad wrote: Since the problem occurs going from 32-bit to 64-bit Cygwin, it sounds to me like all-the-world's-a-VAX syndrome. I bet there are places where it reads from files and assumes that if it reads N words into integers, that is N 32-bit quantities, or something like that. I haven't written any Fortran since the 1980s, but I bet there are types that have changed size due to the switch to 64-bit and that results in reading incorrect values from files, including reading some of them from the wrong file offsets, and hitting end-of-file at a different point. It's called, inadvertent varriable sharing. Yeah, I was there, fought those battles. The proof of what was going on was found in crash dumps. ...This was from the era when RISC architecture meant Relegate all the Important Sh_t to the Compiler. Richard -- 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: g77 on cygwin64
On 12/02/2014 18:35, LMH wrote: Coming back to your issue, it is really curious that gfortran compiles the code but behaves wrongly, I was expecting it rejects the code if not in line with latest standard. This happens on some of my code as well and is in many ways a far worse issue to deal with. Some of my code compiles and runs, but the floating point answers to many of the calculations are wrong. This makes the issue(s) very difficult to run down (and also makes me stick with gcc3 like the posters colleagues). LMH Could you share a test case ? I found no difference in math behaviour on all the Fortran codes in LAPACK and OCTAVE when we moved from G77 to GFORTRAN I am really curious 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: g77 on cygwin64
Scott T. Marshall writes: The strange thing is that gfortran does compile the code, but once compiled, the executables have strange behavior mainly involving problems reading in data files. To me this rather indicates a bug in the code, probably involving bad assumptions about what can be be done to files and in which order. For starters you might check if the files are opened in binary mode. So it is not clear to me exactly what needs to be updated in the code. Big can of worms. I've seen old Fortran code break on seemingly unrelated things like a C library security update, not to say what happened when I first tried to run it on an Alpha. You might try if the program works correctly if compiled unoptimized. Another option is to purposefully use a compiler that does things in a very different way and see where it complains and/or breaks (I've been keeping f2c for that). Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf microQ V2.22R2: 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
newt-0.52.16 patches for Cygwin
I have been wanting to write some python using the newt (snack) module, so I managed to get it to compile pretty cleanly with some minor patching. Is it appropriate for me to submit patches here for whoever else might have a need? Or should I try to contact the maintainer? This is the tarball I started with: https://fedorahosted.org/releases/n/e/newt/newt-0.52.16.tar.gz I have a patch for the snackmodule.c to allow runtime initializing (4 lines of code). Then I needed a bootstrap module (I'm not sure why I needed it if it wasn't needed in linux, perhaps I just don't know how that works in other environments). Finally a patch to the Makefile.in to make it work with Cygwin and install the bootstrap python module. The only other thing to know is when running configure with all the standard Cygwin parameters, I needed to --disable-nls. Oh, and it has a dependency on slang. If patches are appropriate here, let me know and I'll post what I have. Thanks, Mike -- 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: g77 on cygwin64
On 12/02/2014 20:06, Richard wrote: Yeah, I was there, fought those battles. The proof of what was going on was found in crash dumps. ...This was from the era when RISC architecture meant Relegate all the Important Sh_t to the Compiler. Richard More recently, all wchar_t are 4 byte long... It took a while to demonstrate that is was not the cygwin local to be broken 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: get rid of getpwent? (Was: cygwin-1.7.28 getpwent header declaration changes ?)
On Feb 12 11:16, Ken Brown wrote: On 2/12/2014 4:08 AM, Corinna Vinschen wrote: On Feb 11 19:06, Eric Blake wrote: On 02/11/2014 05:06 PM, Warren Young wrote: On 2/11/2014 16:25, David Stacey wrote: getpwent() is called in three different places. To those of you who have investigated these code paths: do any of them look like they couldn't be replaced by getpwnam() or other calls that would let cygwin1.dll do single-record AD/SAM lookups, rather than whole-table/tree scans? That is, do any of these programs really need to visit every record in /etc/passwd? libreadline wants to know how to tab-complete ~foo; to do that, it has to find all usernames beginning with foo. How would you do that without visiting every single record? This seems to be the major usage of getpwent these days. The question is, how bad is it if only a handful entries, or even only a single one (of oneself) show up? Either way, implementing a full getpwent requires to return the local users, the users of the primary domain, and the users of all trusted domains. I know of domains with 200K users and there are probably bigger ones. How long should a search take when a user presses TAB after the ~? And then, shall the process running the getpwent actually cache all of them? This seems really excessive. What about the following compromise: If /etc/passwd exists, then getpwent behaves as it does currently. This part is relatively easy to implement. Otherwise, it returns a handful of entries, or possibly just the current user. The handful entries would be the ones the process has cached at that point in time. The tricky part is that getpwent would have to keep track which entries from the file are in the cache so that those are not accidentally enumerated twice. This gives users a choice. If tab-completion in this situation is important to them, they can keep their /etc/passwd file. There's only one tiny problem. Whatever I think about the full enumerate being right or wrong, I have this vague feeling that I'd like to have this implemented fully at one point. My cat disapproves, but we can't agree on everything, I guess. Another configuration option in /etc/nsswitch.conf might comfort her. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpg8HlgfmOmb.pgp Description: PGP signature
Re: g77 on cygwin64
On 2/12/2014 12:59 PM, David Conrad wrote: On Wed, Feb 12, 2014 at 12:16 PM, Andrey Repin wrote: The strange thing is that gfortran does compile the code, but once compiled, the executables have strange behavior mainly involving problems reading in data files. ... And this is finally the information, that we can work with. My wild guess is that your colleagues making certain assumptions about files, that not always true on other systems. I.e. opening a file in text mode, and then treating [its] data as binary ... Since the problem occurs going from 32-bit to 64-bit Cygwin, it sounds to me like all-the-world's-a-VAX syndrome. I bet there are places where it reads from files and assumes that if it reads N words into integers, that is N 32-bit quantities, or something like t:hat. I haven't written any Fortran since the 1980s, but I bet there are types that have changed size due to the switch to 64-bit and that results in reading incorrect values from files, including reading some of them from the wrong file offsets, and hitting end-of-file at a different point. Are there any switches to gfortran that control this? ifort still has switches for selecting the VAX convention of measuring RECL in 32-bit words vs. the f2003 recommended convention of byte size. gfortran (and afaik g77) used byte lengths only. Note that 32-bit g77 unformatted direct access files were never intended to work with any 64-bit mode compiler (not even the buggy 64-bit g77) and can't be expected to work with gfortran (you would need to make those data files from scratch): http://gcc.gnu.org/onlinedocs/gcc-3.4.4/g77/Portable-Unformatted-Files.html Also important is the point made above that g77 may have allowed indiscriminate switching between formatted and unformatted or direct and sequential access files, or read after write, but the run-time errors should shed light on that, and you would need to watch for unsuspected problems if g77 let it through. -- Tim Prince -- 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: get rid of getpwent? (Was: cygwin-1.7.28 getpwent header declaration changes ?)
On Wed, Feb 12, 2014 at 08:59:31PM +0100, Corinna Vinschen wrote: On Feb 12 11:16, Ken Brown wrote: On 2/12/2014 4:08 AM, Corinna Vinschen wrote: On Feb 11 19:06, Eric Blake wrote: On 02/11/2014 05:06 PM, Warren Young wrote: On 2/11/2014 16:25, David Stacey wrote: getpwent() is called in three different places. To those of you who have investigated these code paths: do any of them look like they couldn't be replaced by getpwnam() or other calls that would let cygwin1.dll do single-record AD/SAM lookups, rather than whole-table/tree scans? That is, do any of these programs really need to visit every record in /etc/passwd? libreadline wants to know how to tab-complete ~foo; to do that, it has to find all usernames beginning with foo. How would you do that without visiting every single record? This seems to be the major usage of getpwent these days. The question is, how bad is it if only a handful entries, or even only a single one (of oneself) show up? Either way, implementing a full getpwent requires to return the local users, the users of the primary domain, and the users of all trusted domains. I know of domains with 200K users and there are probably bigger ones. How long should a search take when a user presses TAB after the ~? And then, shall the process running the getpwent actually cache all of them? This seems really excessive. What about the following compromise: If /etc/passwd exists, then getpwent behaves as it does currently. This part is relatively easy to implement. Otherwise, it returns a handful of entries, or possibly just the current user. The handful entries would be the ones the process has cached at that point in time. The tricky part is that getpwent would have to keep track which entries from the file are in the cache so that those are not accidentally enumerated twice. This gives users a choice. If tab-completion in this situation is important to them, they can keep their /etc/passwd file. There's only one tiny problem. Whatever I think about the full enumerate being right or wrong, I have this vague feeling that I'd like to have this implemented fully at one point. My cat disapproves, but we can't agree on everything, I guess. Another configuration option in /etc/nsswitch.conf might comfort her. I don't know if this has been mentioned but would a cache help here, i.e., nscd? I think that's how Linux deals with this type of situation. cgf -- 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: g77 on cygwin64
On 2/12/2014 9:07 AM, Scott T. Marshall wrote: My colleagues have no interest in fixing it since they have g77 on their unix machines, and to them, it isn't broken. Perhaps your colleagues would be willing to look at your results and tell you whether there is a trivial fix for your problem. gfortran is quite compatible with g77, and since g77 is no longer maintained, your colleagues will also have to replace it sooner or later. -- 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: newt-0.52.16 patches for Cygwin
Greetings, Michael Verrilli! I have been wanting to write some python using the newt (snack) module, so I managed to get it to compile pretty cleanly with some minor patching. Is it appropriate for me to submit patches here for whoever else might have a need? Or should I try to contact the maintainer? Depends on the nature of the patches, I say. If the change is beneficial for a wide audience, it is quite apparent, that the changes should go upstream. This is the tarball I started with: https://fedorahosted.org/releases/n/e/newt/newt-0.52.16.tar.gz I have a patch for the snackmodule.c to allow runtime initializing (4 lines of code). Then I needed a bootstrap module (I'm not sure why I needed it if it wasn't needed in linux, perhaps I just don't know how that works in other environments). Finally a patch to the Makefile.in to make it work with Cygwin and install the bootstrap python module. The only other thing to know is when running configure with all the standard Cygwin parameters, I needed to --disable-nls. Mmm... how much implication this thing cause in reality? Disabling NLS support doesn't sound too right for me. Oh, and it has a dependency on slang. If patches are appropriate here, let me know and I'll post what I have. -- WBR, Andrey Repin (anrdae...@yandex.ru) 13.02.2014, 02:56 Sorry for my terrible english... -- 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: newt-0.52.16 patches for Cygwin
Ok, I'll try to figure out the NLS support. (Post edit, read the end if you don't care about how I got there, it's resolved). I never really got into building configure scripts, but this is what I'm seeing... When I run configure, I see: checking for gettext in -lc... no checking for gettext in -lintl... no and in configure.ac, I see: AC_ARG_ENABLE([nls], [ --disable-nls compile without NLS support]) if test x$enable_nls != xno; then AC_CHECK_LIB([c], [gettext], [ ], [ AC_CHECK_LIB([intl], [gettext], [ LIBS=-lintl AC_SUBST([LIBS])], [ if test x$enable_nls != xcheck; then AC_MSG_FAILURE([--enable-nls was specified, but the configure check failed]) else enable_nls=no fi ]) ]) if test x$enable_nls != xno; then AC_DEFINE([ENABLE_NLS], 1, [Define to 1 if NLS support is enabled]) fi fi It looks to me like... if c.gettext does not exist, check if intl.gettext exists. If that exists, add intl to the lib list, otherwise throw the error I am getting. I would have thought it would detect it in intl, since that is installed. But looking in the cygwin installer, I noticed gettext-0.18.1.1-3 lib. I installed that and the problem is now resolved, only the standard config options for Cygwin are required, thanks for pointing this out. So this would be another dependency in addition to slang (and please let me know if I am doing this wrong, I have a C background from almost 2 decades ago and I'm pretty good with linux but I'm way rusty and out of date). ;-) I also included the patch in case anyone wants to review it and tell me if I am doing something bad. Thanks! On Wed, Feb 12, 2014 at 5:58 PM, Andrey Repin anrdae...@yandex.ru wrote: Greetings, Michael Verrilli! I have been wanting to write some python using the newt (snack) module, so I managed to get it to compile pretty cleanly with some minor patching. Is it appropriate for me to submit patches here for whoever else might have a need? Or should I try to contact the maintainer? Depends on the nature of the patches, I say. If the change is beneficial for a wide audience, it is quite apparent, that the changes should go upstream. This is the tarball I started with: https://fedorahosted.org/releases/n/e/newt/newt-0.52.16.tar.gz I have a patch for the snackmodule.c to allow runtime initializing (4 lines of code). Then I needed a bootstrap module (I'm not sure why I needed it if it wasn't needed in linux, perhaps I just don't know how that works in other environments). Finally a patch to the Makefile.in to make it work with Cygwin and install the bootstrap python module. The only other thing to know is when running configure with all the standard Cygwin parameters, I needed to --disable-nls. Mmm... how much implication this thing cause in reality? Disabling NLS support doesn't sound too right for me. Oh, and it has a dependency on slang. If patches are appropriate here, let me know and I'll post what I have. -- WBR, Andrey Repin (anrdae...@yandex.ru) 13.02.2014, 02:56 Sorry for my terrible english... patch.newt-cygwin Description: Binary data -- 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
OpenSSH port forwarding bug
Hi All... The following example shows the port forwarding problem. ~ $ ssh raven -W coyote:22 getsockname failed: Bad file descriptor SSH-2.0-OpenSSH_6.5 Protocol mismatch. ~ $ ssh raven nc coyote 22 SSH-2.0-OpenSSH_6.5 Protocol mismatch. This is the latest version of everything on a win7-64 pro machine. Thanks, ...Karl -- 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: OpenSSH port forwarding bug
Hi All... The following example shows the port forwarding problem. ~ $ ssh raven -W coyote:22 getsockname failed: Bad file descriptor SSH-2.0-OpenSSH_6.5 Protocol mismatch. ~ $ ssh raven nc coyote 22 SSH-2.0-OpenSSH_6.5 Protocol mismatch. What are you trying to do? -- 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
