Re: emacs-w32 24.5.1: Crashes with --daemon and in About Emacs
On 5/18/2015 1:57 AM, Martin Anantharaman wrote: Ken, so that we do not get side-tracke by differences in our emacs-customizations I now re-produced the error in a clean environment, i.e. I unset ALTERNATE_EDITOR and did the following: Did you also make sure that EMACS_SERVER_FILE was not set? $ emacs --daemon -Q Starting Emacs daemon. $ emacsclient .shrc Waiting for Emacs... *ERROR*: Could not open file: /dev/cons1 So this time emacsclient did not complain that it couldn't find the socket. But why is it trying to open /dev/cons1? Are you running these commands in a Windows console rather than a Cygwin Terminal (mintty)? If so, please try it in a Cygwin Terminal. $ emacsclient .shrc Waiting for Emacs... (emacsclient returns immediately, task-manager shows there is no more emacs-w32 process and there is a new stackdump in the working directory) $ cat emacs-w32.exe.stackdump Stack trace: Frame Function Args 017075E4 61033210 (0558, EA60, 00A4, 01707654) 01707714 610EF12F (0012, , 0170776C, 6110E4AF) To get some more insight I tried to do the same on another machine running Arch Linux (though with emacs 24.3 under LXDE) and guess what: At any number of calls to emacsclient as above a (emacs-)window is opened in the TERMINAL from which I run emacsclient (though a new desktop-window is opened when emacsclient is called with the -c option) - which is not working in my Cygwin/Windows combination giving the error *ERROR*: Could not open file: /dev/cons1 and crashing emacs on the next c. So what happends when you call emacs and then emacsclient in the same order as shown? I get the Linux behavior that you just described. Regarding the 2. problem (crash on About Emacs) it happens exactly the same way when I call emacs with emacs -Q and immediately open About Emacs. I will get the debuginfo and try to see where/why it is crashing when I have a little spare time - I was just hoping that the stackdump I had attached before might actually allow you to localize the error. The two addresses shown in the stackdump (in the Function column) are both in cygwin1.dll. $ addr2line -e /usr/lib/debug/usr/bin/cygwin1.dbg 61033210 /usr/src/debug/cygwin-2.0.2-1/winsup/cygwin/exceptions.cc:1540 $ addr2line -e /usr/lib/debug/usr/bin/cygwin1.dbg 610EF12F /usr/src/debug/cygwin-2.0.2-1/winsup/cygwin/sigproc.cc:714 This doesn't tell us anything about what was happening in emacs. Ken P.S. Please *reply* to my message rather than starting a new message each time, so that you preserve the threading in the archives. -- 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: File operations on a Windows Driver (character device)
On 05/18/2015 05:42 AM, Alessio Faina wrote: Hello everyone, I'm developing a port of a FreeBSD/Linux application that consists of two parts: a kernel and a user land part. The kernel part is build as a WDM driver and is compiled with VS2013 and WDK 8.1: the userspace is going to be compiled under Cygwin for compatibility with user land programs already written for other OSs. My problem is that the user space program invokes Open(), ioctl(), mmap/munmap(), select() and poll(). I've build a test Win32 app to open with CreateFile the DosDevice with the .\\uniioctl name and everything goes fine, but I've tried to do the same thing with Open(...) with a lot of variants (\\DosDevice\\uniioctl, \dev\uniioctl) but I'm unable to open the character device. There is some way to do this? Sorry I can't help with allot of specifics on your questions but I can say that when using Cygwin, you are best off if you stick to POSIX syntax and semantics and don't mix in Windows code and Windowisms. That includes path separators (i.e. use '/', not '\'). See this page in the User's Guide for information on how Cygwin handles device emulation too: https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-posixdevices -- 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: Issue while running Visual Studio's devenv through ssh
I am aware that I am getting a Visual Studio error. The reason this problem is tied to Cygwin is when I log into W, open a Cygwin console, and run build.bat it works, but when I execute the procedure described below (executing build.bat from U through ssh using Cygwin's sshd running on W) it fails. Also, sorry if this shows up as a separate topic, I neglected to subscribe to the list before posting my previous message. For that reason I've included my whole post below. On May 15, 2015, at 1:08 PM, The General the.third.gene...@gmail.com wrote: 1Stdafx.cpp : fatal error C1902: Program database manager mismatch; please check your installation Thatâs a Visual Studio error, not a Cygwin error. Perhaps you have this problem: http://stackoverflow.com/questions/12325096/ If thatâs not it, youâll need to tie this problem to some Cygwin-specific behavior for this thread to be on-topic. On Fri, May 15, 2015 at 3:08 PM, The General the.third.gene...@gmail.com wrote: I have some code that needs to be built on a windows machine (W), but my primary development/deploy environment is an Ubuntu server (U). The goal is to fully automate the build/deploy process so that it can be kicked off from U. Before I describe the problem let me explain my process. U is an Ubuntu 12.04.5 VM running on ESXI W is a Windows 7 VM (Version 6.1.7601) running on ESXI, it has Cygwin installed (with the openssl and git packages included) and UAC disabled. I am running the following command from U: ssh win_user@1.2.3.4 'cd /cygdrive/c/Users/win_user/git_repo/windows_code ./build.bat' I have set up public key authentication from U to W, but I also experience the below issue when I include the '-o PreferredAuthentications=password' switch. build.bat is stored locally on W and looks like this: @echo off git pull call C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat amd64 devenv /nologo windows_code.sln /Build Release|x64 The git pull command is pulling changes from a remote git server (G). I have also set up public key authentication from W to G, disabling this doesn't seem to have any effect. The problem: After I got the above working I took a snapshot of W. If I reset to that snapshot and run the ssh command on U everything works. If I leave W idle for a few hours and try again I get the following from devenv: 1-- Rebuild All started: Project: windows_code, Configuration: Release x64 -- 1 Stdafx.cpp 1Stdafx.cpp : fatal error C1902: Program database manager mismatch; please check your installation Right now I'm at a loss as to why this will work after a snapshot reset, but will stop working if the machine is left alone for awhile. Resetting to the most recent snapshot, rebooting the VM, and then running the ssh command from U will also generate the above error. A temporary solution is to manually reset the VM before kicking off the job, but I'd like to figure out why it stops working after awhile. Any feedback is much appreciated, and if anyone needs more information please don't hesitate to ask. -- 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: File operations on a Windows Driver (character device)
Ok thanks, I've been able to find the character device under /proc/sys/DosDevices/Global/deviceName; now I'm stuck with the mmap implementation; when I do mmap in the userland program it returns me errno 19 (#define ENODEV 19 /* No such device */) obviously because I haven't set anything in the kernel module; there's a way to make visible a portion of memory to be used by the mmap in the kernel? The memory is Non Paged and allocated with a ExAllocatePoolWithTag in 'win terms'. 2015-05-18 16:47 GMT+02:00 Larry Hall (Cygwin) reply-to-list-only...@cygwin.com: On 05/18/2015 05:42 AM, Alessio Faina wrote: Hello everyone, I'm developing a port of a FreeBSD/Linux application that consists of two parts: a kernel and a user land part. The kernel part is build as a WDM driver and is compiled with VS2013 and WDK 8.1: the userspace is going to be compiled under Cygwin for compatibility with user land programs already written for other OSs. My problem is that the user space program invokes Open(), ioctl(), mmap/munmap(), select() and poll(). I've build a test Win32 app to open with CreateFile the DosDevice with the .\\uniioctl name and everything goes fine, but I've tried to do the same thing with Open(...) with a lot of variants (\\DosDevice\\uniioctl, \dev\uniioctl) but I'm unable to open the character device. There is some way to do this? Sorry I can't help with allot of specifics on your questions but I can say that when using Cygwin, you are best off if you stick to POSIX syntax and semantics and don't mix in Windows code and Windowisms. That includes path separators (i.e. use '/', not '\'). See this page in the User's Guide for information on how Cygwin handles device emulation too: https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-posixdevices -- 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 -- 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: emacs-w32 24.5.1: Crashes with --daemon and in About Emacs
On 5/18/2015 8:34 AM, Ken Brown wrote: On 5/18/2015 1:57 AM, Martin Anantharaman wrote: Ken, so that we do not get side-tracke by differences in our emacs-customizations I now re-produced the error in a clean environment, i.e. I unset ALTERNATE_EDITOR and did the following: Did you also make sure that EMACS_SERVER_FILE was not set? $ emacs --daemon -Q Starting Emacs daemon. $ emacsclient .shrc Waiting for Emacs... *ERROR*: Could not open file: /dev/cons1 So this time emacsclient did not complain that it couldn't find the socket. But why is it trying to open /dev/cons1? Are you running these commands in a Windows console rather than a Cygwin Terminal (mintty)? If so, please try it in a Cygwin Terminal. $ emacsclient .shrc Waiting for Emacs... (emacsclient returns immediately, task-manager shows there is no more emacs-w32 process and there is a new stackdump in the working directory) $ cat emacs-w32.exe.stackdump Stack trace: Frame Function Args 017075E4 61033210 (0558, EA60, 00A4, 01707654) 01707714 610EF12F (0012, , 0170776C, 6110E4AF) To get some more insight I tried to do the same on another machine running Arch Linux (though with emacs 24.3 under LXDE) and guess what: At any number of calls to emacsclient as above a (emacs-)window is opened in the TERMINAL from which I run emacsclient (though a new desktop-window is opened when emacsclient is called with the -c option) - which is not working in my Cygwin/Windows combination giving the error *ERROR*: Could not open file: /dev/cons1 and crashing emacs on the next c. So what happends when you call emacs and then emacsclient in the same order as shown? I get the Linux behavior that you just described. Regarding the 2. problem (crash on About Emacs) it happens exactly the same way when I call emacs with emacs -Q and immediately open About Emacs. I will get the debuginfo and try to see where/why it is crashing when I have a little spare time - I was just hoping that the stackdump I had attached before might actually allow you to localize the error. The two addresses shown in the stackdump (in the Function column) are both in cygwin1.dll. $ addr2line -e /usr/lib/debug/usr/bin/cygwin1.dbg 61033210 /usr/src/debug/cygwin-2.0.2-1/winsup/cygwin/exceptions.cc:1540 $ addr2line -e /usr/lib/debug/usr/bin/cygwin1.dbg 610EF12F /usr/src/debug/cygwin-2.0.2-1/winsup/cygwin/sigproc.cc:714 This doesn't tell us anything about what was happening in emacs. And here too I recommend starting emacs from a Cygwin Terminal if that isn't what you've been doing. 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: [EXTERNAL] Re: startxwin - xinit unable to connect to X server
Looks like Jon was 100% correct. For me it appears to have been Symantec Endpoint Protection causing the problem. Updated / added exception and the problem has resolved. Thanks! -Original Message- From: Jon TURNEY [mailto:jon.tur...@dronecode.org.uk] Sent: Friday, May 15, 2015 11:02 To: Kunz, Christopher L; cygwin@cygwin.com Subject: Re: [EXTERNAL] Re: startxwin - xinit unable to connect to X server On 15/05/2015 18:36, Kunz, Christopher L wrote: After installing the 64 bit version of Cygwin, I don't experience this problem. Backtrace output: gdb: unknown target exception 0x8001 at 0x5dd96d61 Program received signal ?, Unknown signal. [Switching to Thread 8216.0x2374] 0x5dd96d61 in sysfer!FirstHookFunc () from /cygdrive/c/Windows/SysWOW64/SYSFER.DLL (gdb) bt full #0 0x5dd96d61 in sysfer!FirstHookFunc () from /cygdrive/c/Windows/SysWOW64/SYSFER.DLL No symbol table info available. #1 0x in ?? () No symbol table info available. (gdb) Thanks. The injected sysfer.dll belongs to Symantec Endpoint Protection See [1] for a previous incident. As discussed there, I suggest you try updating SEP, or creating an exception for XWin. [1] https://cygwin.com/ml/cygwin/2015-03/msg00080.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer
Re: run.exe fails to start XWin in Windows 8.1
On 02/05/2015 20:32, jaakov jaakov wrote: While executing the command Xwin Server from Windows 8.1, the server won't start. Apparently, the executed command is C:\cygwin64\bin\run.exe --quote /usr/bin/bash.exe -l -c cd; /usr/bin/startxwin The file C:\cygwin64\run.exe.stackdump is produced. Instead I expect, however, an X server process and an xterm window. On the other hand, starting first Cygwin64 terminal does create a text console shell, and running startxwin from this shell does give me an X server process and an xterm window. A complete removal of the C:\cygwin64 directory and reinstalling did not help. Afterwards, reinstalling xinit did not help. This issue persists for a few months already. Last year, XWin started without problems. Unfortunately, the stackdump in your previous report [1] didn't quite contain enough information to investigate this problem. I've made a small improvement in how the stackdumps are made [2] since then, so if you can upgrade and provide the stackdump file, perhaps we can discover why this crash is happening. [1] https://cygwin.com/ml/cygwin/2015-03/msg00117.html [2] https://cygwin.com/ml/cygwin-patches/2015-q1/msg00018.html -- 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-2 process handling
Since the upgrade to cygwin-2 I've been having consistent problems using emacs. My emacs config has not changed and the most recent update to cygwin-2 has helped. I'm using the emacs-w32 executable and have numerous remote cygwin ssh sessions running underneath emacs so that I can edit remote files and run remote shell sessions within emacs. When I then start up a Windows console executable (in my case Oracles sqlplus.exe, but cmd.exe works too), I start getting hanging in the cygwin ssh sessions. Filename completion (which involves emacs interacting with a ssh session) or opening a remote file (which involves emacs transferring the file locally via scp or inline) will both hang. It generally requires that I send a SIGUSR2 signal to the emacs-w32 process which emacs responds to by halting whatever is running and returning to the top level interaction loop. When it does so, the process appears to be waiting for input. If I then end the console session, the interaction returns to normal. Trying to start a second Windows console session will also hang. In Emacs *scratch* buffer (shell *One*) C-j #buffer *One* (shell *Two*) C-j #buffer *Two* (let ((explicit-shell-file-name /c/Windows/System32/cmd.exe)) (shell *Three*)) C-j #buffer *Three* (let ((explicit-shell-file-name /c/Windows/System32/cmd.exe)) (shell *Four*)) C-j *** HANGS *** Things dramatically improved with Cygwin-2.0.2-1 restores the #include sys/select.h in sys/time.h. I could run more than one process at a time, and worked perfectly prior to cygwin-2. MICHAEL MAUGER // FSF Member // GNU Emacs sql-mode maintainer // GNU Linux, GNU Emacs, OwnCloud -- 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: run.exe fails to start XWin in Windows 8.1
While executing the command Xwin Server from Windows 8.1, the server won't start. Apparently, the executed command is C:\cygwin64\bin\run.exe --quote /usr/bin/bash.exe -l -c cd; /usr/bin/startxwin The file C:\cygwin64\run.exe.stackdump is produced. Instead I expect, however, an X server process and an xterm window. On the other hand, starting first Cygwin64 terminal does create a text console shell, and running startxwin from this shell does give me an X server process and an xterm window. A complete removal of the C:\cygwin64 directory and reinstalling did not help. Afterwards, reinstalling xinit did not help. This issue persists for a few months already. Last year, XWin started without problems. Unfortunately, the stackdump in your previous report [1] didn't quite contain enough information to investigate this problem. I've made a small improvement in how the stackdumps are made [2] since then, so if you can upgrade and provide the stackdump file, perhaps we can discover why this crash is happening. [1] https://cygwin.com/ml/cygwin/2015-03/msg00117.html [2] https://cygwin.com/ml/cygwin-patches/2015-q1/msg00018.html Great, I'll test it as soon as possible! -- 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 - configure: error: Required header rpc/types.h not found
Hello, I received a SUNRPC error after running ./configure on version 5.4.2220 in Cygwin (CYGWIN_NT-6.3-WOW64 gery 1.7.32(0.274/5/3) 2014-08-13 23:03 i686 Cygwin), here it is: configure: error: Required header rpc/types.h not found, check include path and intsalled devel packages SUNRPC (as well as libtirpc) is located in my Cygwin system: Gery@gery /opt/mb/mbsystem-5.4.2220 $ cygcheck -c | grep rpc libgssrpc4 1.12.2-1 OK libtirpc-common 0.2.4-1 OK libtirpc-debuginfo 0.2.4-1 OK libtirpc-devel 0.2.4-1 OK libtirpc1 0.2.4-1 OK php-xmlrpc 5.5.18-1 OK rpcgen 2.11.90_20100818-1 OK sunrpc 4.0-4 OK Any idea to solve this configure error? I mean, a solution that doesn't involve upgrading cygwin to the latest version, I just don't want to reinstall everything again. Any support is welcomed, thanks in advance, Gery PS: see below please the details of install_makefiles and ./configure output My install_makefiles is here: # # EDIT THE PARAMETERS HERE IF NO APPROPRIATE PRESET CONFIGURATION IS DEFINED # Set the configuration parameters manually: # # # Required parameters: $MBSYSTEM_HOME = /opt/mb/mbsystem-5.4.2220; $OS = CYGWIN; $CFLAGS = -g -fdata-sections -I/usr/include/rpcsvc -I/usr/X11R6/include -I/usr/X11R6/lib; $LFLAGS = -lrpc -lrpclib -lm -Wl,--enable-runtime-pseudo-reloc; $NETCDFLIBDIR = /usr/src/debug/netcdf-4.3.2-1/lib; $NETCDFINCDIR = /usr/src/debug/netcdf-4.3.2.1/include; $GMTLIBDIR = /opt/gmt/gmt-4.5.9/lib; $GMTINCDIR = /opt/gmt/gmt-4.5.9/include; $PROJECTIONS = $MBSYSTEM_HOME/share/Projections.dat; $MOTIFINCDIR = /usr/X11R6/include/Xm; $MOTIFLIBS = -L/usr/X11R6/lib -lXm -lXt -lX11; $OPENGLLIBS = -lGLU -lGL; $LEVITUS = $MBSYSTEM_HOME/share/annual; $CC = gcc; # # END OF PARAMETER EDITING SECTION # Here the last part of the ./configure output: #-# Configure will now attempt to construct the Makefiles required to build MB-System MB-System Version 5.4.2220 HOST System Type: i686-pc-cygwin checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking dependency style of gcc... gcc3 checking for ar... ar checking the archiver (ar) interface... ar checking whether ln -s works... yes checking whether make sets $(MAKE)... (cached) yes checking how to print strings... printf checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by gcc... /usr/i686-pc-cygwin/bin/ld.exe checking if the linker (/usr/i686-pc-cygwin/bin/ld.exe) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking the maximum length of command line arguments... 8192 checking whether the shell understands some XSI constructs... yes checking whether the shell understands +=... yes checking how to convert i686-pc-cygwin file names to i686-pc-cygwin format... func_convert_file_noop checking how to convert i686-pc-cygwin file names to toolchain format... func_convert_file_noop checking for /usr/i686-pc-cygwin/bin/ld.exe option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL checking for dlltool... dlltool
Re: [ITA] inetutils
On Apr 3 13:12, D. Boland wrote: I noticed that the package is orphaned. I 'd like to adopt it. Sure, adopting orphaned packages is super. Gold star awarded: http://cygwin.com/goldstars/#DB
Re: [ITA] xclip-0.12: Command line clipboard grabber
On Apr 23 14:21, Dr. Volker Zell wrote: Marco Atzeri writes: On 4/23/2015 1:53 PM, Dr. Volker Zell wrote: Hi I would like to adopt and maintain the orphaned 'xclip' package. already your https://cygwin.com/cygwin-pkg-maint I presume Corinna touched it, but there is no trace in the cvs log. Can I upload ? Did you checked the package ? Yes, please go ahead. Gold star awarded: http://cygwin.com/goldstars/#VZ
RE: Cygwin - configure: error: Required header rpc/types.h not found
Add CPPFLAGS=-I/usr/include/tirpc to your configure flags. now found it, thanks for the tip again. Gery -- 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: [ITA] mosh
On Fri, 2015-05-15 at 23:06 +0200, Achim Gratz wrote: Mosh has been orphaned by Reini Urban and the setup.hint in 32bit is currently having a wrong dependency. I'm using mosh and would like to take over maintenance. Since there was no intervening upstream release, I've simply rebuilt using cygport and the latest toolchain. GTG, please proceed. Gold star awarded: http://cygwin.com/goldstars/#AG
Re: Obsolete dependency report, 2015-May-15 [GOLDSTAR]
On Sat, 2015-05-16 at 10:56 +0200, Marco Atzeri wrote: I am uploading the dependencies of singular now and testing Yue's last monolithic proposal. If it passes the test as expected I will also upload both archs during weekend. Wonderful! Thank you very much for helping with this. Andrew? This has been a lot more work than an average ITA; could Marco get two gold stars please? Awarded! http://cygwin.com/goldstars/#MA
Re: [PLUSH HIPPO] Re: [ITA] maxima-5.35.1
On Mon, 2015-05-18 at 17:41 -0400, Andrew Schulman wrote: On Mar 5 20:54, Achim Gratz wrote: In order to reap the fruits of Ken Brown's work on clisp and its dependencies (which seem to have escaped the attention of the plush hippo hordes so far) What? That's inexcusable. Andrew, one plush hippo for Ken, please. OK, sure. But I'm having trouble finding it... can you please point me to a cygwin-apps post? Hard to point to just one, but you could use this: https://cygwin.com/ml/cygwin-apps/2015-02/msg00186.html Awarded! http://cygwin.com/goldstars/#KB BTW, any news on rebuilding sng? https://cygwin.com/ml/cygwin-apps/2015-02/msg00152.html No, as you've probably noticed I haven't been able to spend time on Cygwin lately. Thanks for the reminder, though. I'll get to it when I can. Andrew
Re: Cygwin - configure: error: Required header rpc/types.h not found
https://cygwin.com/acronyms/#PCYMTWLL ! On Mon, 2015-05-18 at 19:17 +, Gery . wrote: I received a SUNRPC error after running ./configure on version 5.4.2220 in Cygwin (CYGWIN_NT-6.3-WOW64 gery 1.7.32(0.274/5/3) 2014-08-13 23:03 i686 Cygwin), here it is: configure: error: Required header rpc/types.h not found, check include path and intsalled devel packages Any idea to solve this configure error? Add CPPFLAGS=-I/usr/include/tirpc to your configure flags. I mean, a solution that doesn't involve upgrading cygwin to the latest version, I just don't want to reinstall everything again. Please note that we do not support old versions of Cygwin, nor does upgrading to the currently supported version require reinstalling everything. -- Yaakov -- 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: Cygwin - configure: error: Required header rpc/types.h not found
Thanks Yaakov for the quick reply, https://cygwin.com/acronyms/PCYMTWLL ! sorry for the long lines =) Add CPPFLAGS=-I/usr/include/tirpc to your configure flags. Thanks, but the problem remains. MB-System (the software I try to install) complains about rpc/: ... ... checking rpc/rpc.h usability... no checking rpc/rpc.h presence... no checking for rpc/rpc.h... no checking rpc/types.h usability... no checking rpc/types.h presence... no checking for rpc/types.h... no configure: error: Required header rpc/types.h not found, check include path and intsalled devel packages I mean, a solution that doesn't involve upgrading cygwin to the latest version, I just don't want to reinstall everything again. Please note that we do not support old versions of Cygwin, nor does upgrading to the currently supported version require reinstalling everything. I always knew that I must reinstall all software (those that don't come with cygwin by default, e.g., PostGIS) after upgrading to the latest cygwin version (ie. download the latest setup*.exe and perform the upgrade). I just found these steps: wget http://apt-cyg.googlecode.com/svn/trunk/apt-cyg chmod +x apt-cyg mv apt-cyg /usr/local/bin/ apt-cyg install PACKAGE-NAME-HERE would these steps correctly update specific packages? Thanks again, Gery -- 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: [PLUSH HIPPO] Re: [ITA] cygwin-doc
On Mar 13 14:29, Jon TURNEY wrote: As invited [1], I shall adopt the cygwin-doc package. That's definitely a pink plush hippo for you. I made you maintainer in cygwin-pkg-maint. Awarded! http://cygwin.com/goldstars/#JTy
Re: [PLUSH HIPPO] Re: [ITA] maxima-5.35.1
On Mon, 2015-05-18 at 17:41 -0400, Andrew Schulman wrote: On Mar 5 20:54, Achim Gratz wrote: In order to reap the fruits of Ken Brown's work on clisp and its dependencies (which seem to have escaped the attention of the plush hippo hordes so far) What? That's inexcusable. Andrew, one plush hippo for Ken, please. OK, sure. But I'm having trouble finding it... can you please point me to a cygwin-apps post? Hard to point to just one, but you could use this: https://cygwin.com/ml/cygwin-apps/2015-02/msg00186.html BTW, any news on rebuilding sng? https://cygwin.com/ml/cygwin-apps/2015-02/msg00152.html -- Yaakov
rpc/types.h: No such file or directory
I'm still installing MBsystem software in cygwin and it fails here: surf.h:58:23: fatal error: rpc/types.h: No such file or directory #include rpc/types.h it doesn't find rpc/types.h, even though both are in /usr/include/tirpc/rpc. I run export CPPFLAGS=-I/usr/include/tirpc/rpc with no effect. Any clues to solve this? I will appreciate your support, thanks in advance Gery ps. uname -a CYGWIN_NT-6.3-WOW64 gery 1.7.32(0.274/5/3) 2014-08-13 23:03 i686 Cygwin libgssrpc4 1.12.2-1 OK libtirpc-common 0.2.4-1 OK libtirpc-debuginfo 0.2.4-1 OK libtirpc-devel 0.2.4-1 OK libtirpc1 0.2.4-1 OK php-xmlrpc 5.5.18-1 OK rpcgen 2.11.90_20100818-1 OK sunrpc 4.0-4 OK $ ls /usr/include/tirpc/rpc auth.h auth_kerb.h clnt_soc.h des_crypt.h pmap_prot.h rpc.h rpcb_clnt.h rpcent.h svc_dg.h xdr.h auth_des.h auth_unix.h clnt_stat.h nettype.h pmap_rmt.h rpc_com.h rpcb_prot.h svc.h svc_soc.h auth_gss.h clnt.h des.h pmap_clnt.h raw.h rpc_msg.h rpcb_prot.x svc_auth.h types.h -- 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: vim-7.4.729-1
The following packages have been updated in the Cygwin distribution: * vim-7.4.729-1 * vim-common-7.4.729-1 * vim-minimal-7.4.729-1 * xxd-7.4.729-1 * gvim-7.4.729-1 Vim is an advanced text editor that seeks to provide the power of the de-facto Unix editor 'Vi', with a more complete feature set and a choice of terminal and GTK+ interfaces. This is an update to the latest upstream patchset. -- Yaakov -- 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: webkitgtk-2.0.4-4
The following packages have been updated in the Cygwin distribution: * libjavascriptcoregtk1.0_0-2.0.4-4 * libjavascriptcoregtk1.0-devel-2.0.4-4 * jsc1-2.0.4-4 * libjavascriptcoregtk3.0_0-2.0.4-4 * libjavascriptcoregtk3.0-devel-2.0.4-4 * jsc3-2.0.4-4 * libwebkitgtk1.0_0-2.0.4-4 * libwebkitgtk1.0-devel-2.0.4-4 * girepository-WebKit1.0-2.0.4-4 * libwebkitgtk3.0_0-2.0.4-4 * libwebkitgtk3.0-devel-2.0.4-4 * girepository-WebKit3.0-2.0.4-4 * libwebkitgtk-doc-2.0.4-4 WebKitGTK+ is a full-featured port of the WebKit rendering engine, suitable for projects requiring any kind of web integration, from hybrid HTML/CSS applications to full-fledged web browsers. It’s the official web engine of the GNOME platform and is used in browsers such as Epiphany and Midori. This release is a rebuild against the latest version of icu. -- Yaakov -- 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] GNOME 3.14 updates, May 2015
The following packages (and their respective subpackages) have been updated in the Cygwin distribution: * clutter1.0-1.20.2-1 * evolution-data-server-3.12.11-2 * gedit-code-assistance-3.14.3-1 * gnome-control-center-3.14.5-1 * gnome-mines-3.14.2-1 * gnome-online-accounts-3.14.4-1 * gnome-settings-daemon-3.14.4-1 * gnome-tweak-tool-3.14.3-1 * gsettings-desktop-schemas-3.14.2-1 * goffice0.10-0.10.22-1 * gtk2.0-2.24.28-1 * gtk3-3.14.13-1 * gtksourceview3.0-3.14.4-1 * libgsf-1.14.33-1 * libgweather-3.14.4-1 * librsvg2-2.40.9-1 * totem-pl-parser-3.10.5-1 * vte2.90-0.36.4-1 * yelp-3.14.2-1 These are the latest bugfix releases for the GNOME 3.14 stable branch. -- Yaakov -- 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: ncurses-5.9-20150516-1
The following packages have been updated in the Cygwin distribution: * ncurses-5.9-20150516-1 * ncurses-demo-5.9-20150516-1 * libncurses10-5.9-20150516-1 (x86 only) * libncursesw10-5.9-20150516-1 * libncurses-devel-5.9-20150516-1 * terminfo-5.9-20150516-1 * terminfo-extra-5.9-20150516-1 Ncurses (new curses) started as a freely distributable clone of SVr4 curses. It has outgrown the clone description, and now contains many features which are not in SVr4 curses. Curses is a pun on the term cursor optimization. It is a library of functions that manage an application's display on character-cell terminals. This release updates ncurses to the latest upstream patch release. -- Yaakov -- 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
Updated: vim-7.4.729-1
The following packages have been updated in the Cygwin distribution: * vim-7.4.729-1 * vim-common-7.4.729-1 * vim-minimal-7.4.729-1 * xxd-7.4.729-1 * gvim-7.4.729-1 Vim is an advanced text editor that seeks to provide the power of the de-facto Unix editor 'Vi', with a more complete feature set and a choice of terminal and GTK+ interfaces. This is an update to the latest upstream patchset. -- Yaakov
[ANNOUNCEMENT] New: libepoxy-1.2-1
The following packages have been added to the Cygwin distribution: * libepoxy0-1.2-1 * libepoxy-devel-1.2-1 Epoxy is a library for handling OpenGL function pointer management for you. It hides the complexity of dlopen(), dlsym(), glXGetProcAddress(), eglGetProcAddress(), etc. from the app developer, with very little knowledge needed on their part. They get to read GL specs and write code using undecorated function names like glCompileShader(). This library has been added as a prerequisite of GTK+ 3.16. -- Yaakov -- 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: [PLUSH HIPPO] Re: [ITA] maxima-5.35.1
On Mar 5 20:54, Achim Gratz wrote: In order to reap the fruits of Ken Brown's work on clisp and its dependencies (which seem to have escaped the attention of the plush hippo hordes so far) What? That's inexcusable. Andrew, one plush hippo for Ken, please. OK, sure. But I'm having trouble finding it... can you please point me to a cygwin-apps post? I'm proposing to resurrect maxima as a Cygwin package. The packaging is modeled after openSUSE. Resurrect? We had that already at one point? You're fishing for hippos, too, it seems ;) Gold star awarded: http://cygwin.com/goldstars#AG
Updated: ncurses-5.9-20150516-1
The following packages have been updated in the Cygwin distribution: * ncurses-5.9-20150516-1 * ncurses-demo-5.9-20150516-1 * libncurses10-5.9-20150516-1 (x86 only) * libncursesw10-5.9-20150516-1 * libncurses-devel-5.9-20150516-1 * terminfo-5.9-20150516-1 * terminfo-extra-5.9-20150516-1 Ncurses (new curses) started as a freely distributable clone of SVr4 curses. It has outgrown the clone description, and now contains many features which are not in SVr4 curses. Curses is a pun on the term cursor optimization. It is a library of functions that manage an application's display on character-cell terminals. This release updates ncurses to the latest upstream patch release. -- Yaakov
[ANNOUNCEMENT] Updated: harfbuzz-0.9.40-1
The following packages have been updated in the Cygwin distribution: * harfbuzz-0.9.40-1 * libharfbuzz0-0.9.40-1 * libharfbuzz-icu0-0.9.40-1 * libharfbuzz-devel-0.9.40-1 HarfBuzz is an OpenType text shaping engine. This is an update to the latest upstream release, built for icu-55. -- Yaakov -- 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
File operations on a Windows Driver (character device)
Hello everyone, I'm developing a port of a FreeBSD/Linux application that consists of two parts: a kernel and a user land part. The kernel part is build as a WDM driver and is compiled with VS2013 and WDK 8.1: the userspace is going to be compiled under Cygwin for compatibility with user land programs already written for other OSs. My problem is that the user space program invokes Open(), ioctl(), mmap/munmap(), select() and poll(). I've build a test Win32 app to open with CreateFile the DosDevice with the .\\uniioctl name and everything goes fine, but I've tried to do the same thing with Open(...) with a lot of variants (\\DosDevice\\uniioctl, \dev\uniioctl) but I'm unable to open the character device. There is some way to do this? For the second main problem, I need to do an mmap/munmap; I was thinking to emulate this mechanism with an IOCTL in the kernel module but doing so, I wouldn't be able to use the mmap provided by Cygwin if I've understood how the things are working; so I'm wondering how to cope with this problem; there's some way to explicitly tell Cygwin where to find the memory that needs to be allocated in userspace? How can I do this in the kernel module? Thanks everyone, -Alessio -- 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
