Re: pango, gdk-pixbuf and gtk+-3 packaging request
On 4/13/2012 2:38 PM, Pavel Holejsovsky wrote: gnome 3.2 versions of cygwin packages mentioned in subject suffer from gobject-introspection bug described in https://bugzilla.gnome.org/show_bug.cgi?id=672133 The patches fixing the problem were pushed into gnome git repositories, unfortunately, they did not make it into packages for gnome 3.4. Today released GNOME 3.4.1 already contains patches for Gtk3 and GdkPixbuf, so the remaining candidate is the one for Pango, which unfortunately did not seem to get new release for 3.4.1. pango: http://bugzilla-attachments.gnome.org/attachment.cgi?id=211258 Pavel -- 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
pango, gdk-pixbuf and gtk+-3 packaging request
Hello, gnome 3.2 versions of cygwin packages mentioned in subject suffer from gobject-introspection bug described in https://bugzilla.gnome.org/show_bug.cgi?id=672133 The patches fixing the problem were pushed into gnome git repositories, unfortunately, they did not make it into packages for gnome 3.4. Would it be possible to add the patches when packaging gnome 3.4 versions of these packages? pango: http://bugzilla-attachments.gnome.org/attachment.cgi?id=211258 gdk-pixbuf: http://bugzilla-attachments.gnome.org/attachment.cgi?id=211259 gtk-3: http://bugzilla-attachments.gnome.org/attachment.cgi?id=211257 thanks, Pavel -- 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: Problem with .NET applications and pipes in 1.7.11
On 3/14/2012 8:11 AM, David Lindstrom wrote: Hi everyone. As some other people have reported, there seems to be some problem with pipes in 1.7.11 which appears to have been introduced in 1.7.10. I can confirm that 1.7.9 and 1.7.7 works as expected, but I don't have a 1.7.10 installation so I cannot test that. Others have reported problems with that though. Please try the latest snapshot[1], it fixed the problem for me. Pavel [1] http://www.cygwin.com/snapshots -- 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: Problems with emacs built against gtk3
On 11/30/2011 4:51 AM, Yaakov (Cygwin/X) wrote: 2. The pango warning can already be observed with the current Cygwin emacs after the recent update of the GNOME libraries. To reproduce, install the emacs-X11 package and start emacs with the command `emacs' in an xterm window. I cannot reproduce this. Does installing font-cantarell-otf help? Perhaps another font? I can reproduce it, in fact almost every gtk-enabled application spits that out. I tried stracing, and I think (but I'm not sure) that the warning appears after pango tries to load /usr/lib/pango/1.6.0/modules/pango-basic-fc.dll - there is no /usr/lib/pango directory on my system, and it seems that no package in cygwin or ports repository provides it. HTH, Pavel -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: R: getsockopt(SO_KEEPALIVE) returns incorrect option length
On 7/2/2010 12:01 PM, Marco Atzeri wrote:
--- Ven 2/7/10, Pavel Holejsovsky ha scritto:
Hi,
I think that following problem shows problematic behavior
in cygwin 1.7.5, at least incompatible with linux:
#includestdio.h
#includesys/socket.h
int main() {
int sock, option, optlen =
sizeof(int);
sock = socket(AF_INET,
SOCK_STREAM, 0);
getsockopt(sock, SOL_SOCKET,
SO_KEEPALIVE,option,optlen);
printf(option=%d,
optlen=%d\n, option, optlen);
return 0;
}
Prints optlen=1, while it is expected to be sizeof(int),
i.e. 4.
This is most probably because uinderlying winsock call has
this (mis)behavior, but I think that in cygwin layer this
could be worked around to be more unix compatible.
This issue is relevant:
SO_KEEPALIVE value is actually a char on Windows, not BOOL
https://bugzilla.gnome.org/show_bug.cgi?id=611756
And causes glib gio 2.24 to fail certain socket operations
on cygwin.
thanks,
Pavel
option=0, optlen=4
on XP-sp2, cygwin 1.7.5s(0.227/5/3) 20100628
Thanks for testing, Marco.
So it is even system-dependent misbehaviour of winsock. On w7-x64
cygwin 1.7.5 it prints
option=2674688, optlen=1
Pavel
--
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: sed: 4.1.5 breaks libtool generation
Corinna Vinschen wrote: On Feb 24 04:01, Charles Wilson wrote: Yaakov S (Cygwin Ports) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After a recent update to my Cygwin installation, suddenly configure-generated libtool scripts give me this error when compiling and linking C++ code: libtool: ignoring unknown tag CXX And even worse, it tries to use gcc to link, which of course fails because of undefined symbols provided by libstdc++. Using the /usr/bin/libtool instead works, so this would seem to be caused during the generation of the package libtool. So I guessed that the sed update was the problem, and I was right. Downgrading sed to 4.1.4-1 makes everything work again. I'm attaching my cygcheck output (before I downgraded sed). Thanks for the heads up. I'll try to look in to it, but it might be a week or two. I would appreciate any hint here. sed 4.1.5-1 has 0 FAILs in the sed testsuite and the only really interesting Cygwin related difference between 4.1.4 and 4.1.5 is that 4.1.4 uses sed's own implementation of getline(), while 4.1.5 uses the newlib version of getline. One incompatibility of 4.1.5 is that sed no longer works correctly with CRLF-style files on binary mounts. For example, 's/^$//' script no longer filters out empty lines if they are CRLF terminated, but works OK for LF terminated lines. However, I'm not sure whether this causes the problem described above. Pavel -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: sed: 4.1.5 breaks libtool generation
Pavel Holejsovsky wrote: One incompatibility of 4.1.5 is that sed no longer works correctly with CRLF-style files on binary mounts. For example, 's/^$//' script no longer filters out empty lines if they are CRLF terminated, but works OK for LF terminated lines. However, I'm not sure whether this causes the problem described above. I'm sorry, my example script was of course wrong, correct one to demonstrate the problem is e.g. '/^$/d' Pavel -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: snapshots R us
I've similar experience, but I believe even stranger one. After installing 1.3.19, I saw the message about shared version mismatch, but the numbers were different, unfortunately I didn't write them down:-(. I made sure that I have really only one cygwin1.dll in the system. I also used sysinternals HandleEx tools to check that no running process has loaded cygwin1.dll library. The error was still here. Finally, I tried 'strace bash.exe' - the error magically disappeared and then I could run everything normally. This is no big deal for me, just wanted to let you know. Pavel [EMAIL PROTECTED] wrote: Gary R. Van Sickle wrote: On Tue, Oct 22, 2002 at 08:52:50PM -0500, Gary R. Van Sickle wrote: Just installed it (WinXP), getting this: c:\WINDOWSuname c:\unix\bin\uname.exe: *** shared version mismatch detected - 0xBC3E/0x3E. You have multiple copies of cygwin1.dll on your system. Search for cygwin1.dll using the Windows Start-Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. No multiple copies of cygwin1.dll on my system. But there is a cygwin process running somewhere. Otherwise you wouldn't be getting this error. This indicates that cygwin's shared memory is already initialized, which wouldn't be the case if you run 'uname' from the command prompt as the only cygwin process on the system. The last resort is rebooting if nothing else works. Ok, that was weird. No visible Cygwin processes according to Task Manager, but sure enough, a reboot freed that shared memory. And Perl is now working as well. It's like Christmas in October! I've just had the same error message after upgrading from 1.3.18 to 1.3.19 when starting a bash shell. I closed all bash shells down before upgrading. The Task Manager showed no Cygwin processes running. However, as Chris suggests might be the case, Cygwin is being used. The problem is because I launched gvim (native Windows build) from the Cygwin shell as a background task before upgrading: gvim file Only after closing these instances, could I launch a bash shell without the shared version mismatch detected error. Might I suggest the error message is expanded to include something along the lines: Also check that you have no Cygwin processes running, including background tasks launched from a different version of Cygwin. Cheers William -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: More pipe (and other) improvements in snapshot
20021214 snapshot seems to work ok, my testcase below does not fail any more. Thanks! Pavel [EMAIL PROTECTED] wrote: On Sat, Dec 14, 2002 at 12:37:43AM -0500, Christopher Faylor wrote: On Sat, Dec 14, 2002 at 12:27:44AM -0500, Christopher Faylor wrote: On Fri, Dec 13, 2002 at 03:48:28PM +0100, Pavel Holejsovsky wrote: [EMAIL PROTECTED] wrote: Christopher Faylor wrote: On Thu, Dec 12, 2002 at 07:32:16AM -0500, Norman Vine wrote: Any 'tips' as to how to best debug this appreciated - Attach to the hung process with gdb and see where it is hung. - Provide cygcheck output. - Run under strace and see if you can infer where hangs or problems are occurring. The hung process (sed) is actually not hung, but connected to stdin instead of file. The root cause is that when config.status is processed by bash, then sometimes `` construct forgets all output, causing different generated file names to be empty, thus connecting sed to stdin instead of some file. Following command line reproduces the bug for me: while true; do test `echo foo` = foo || echo failed; done When this command is run inside bash, then failed lines appear quite regularly. The bug is reproducible only with /bin/bash, /bin/sh works reliably. I meant to test the above before I made some more changes to cygwin to attempt to avoid data loss but I didn't get around to it. So, there is a snapshot up there which may or may not solve the problem. The above command doesn't die for me now, so I guess that's something. I'll check the prevous snapshot tomorrow to see if it actually fails for me. I've been a little sick for a couple of weeks now and attempting to stay with my work on real job in the day and cygwin at night scenario is not working too well. In the meantime, please try the current snapshot. It is probably slightly (but possibly unoticeably) slower but it should be very much less likely to lose data in a pipe. The latest snapshot also has some new inline assembly functions courtesy of some cygwin-developers (Gary R. Van Sickle and Thomas Pfaff) which might cause a little bit of a boost, too. Nevermind. I just tried the current snapshot on my NT4 machien and it puked all over the place. I'll fix it tomorrow. Please avoid this snapshot until then. This should be fixed now. Please try the latest snapshot. Corinna also tracked down some thinkos in my handling of text mode reads which are fixed in this snapshot. Thanks, Corinna. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pipe improvements in snapshot
[EMAIL PROTECTED] wrote:
Christopher Faylor wrote:
On Thu, Dec 12, 2002 at 07:32:16AM -0500, Norman Vine wrote:
Any 'tips' as to how to best debug this appreciated
- Attach to the hung process with gdb and see where it is hung.
- Provide cygcheck output.
- Run under strace and see if you can infer where hangs or problems
are occurring.
The hung process (sed) is actually not hung, but connected to stdin
instead of file. The root cause is that when config.status is processed
by bash, then sometimes `` construct forgets all output, causing
different generated file names to be empty, thus connecting sed to stdin
instead of some file. Following command line reproduces the bug for me:
while true; do test `echo foo` = foo || echo failed; done
When this command is run inside bash, then failed lines appear quite
regularly. The bug is reproducible only with /bin/bash, /bin/sh works
reliably.
Pavel
P.S. I'm leaving today, I won't answer emails till January 6th, sorry..
Cygwin Win95/NT Configuration Diagnostics
Current System Time: Fri Dec 13 15:44:58 2002
Windows XP Professional Ver 5.1 Build 2600 Service Pack 1
Path: f:\cygwin\usr\local\bin
f:\cygwin\bin
f:\cygwin\usr\X11R6\bin
c:\cygwin-mounts\opt\gnome2\bin
f:\bin
f:\Program Files\Microsoft Platform SDK\Bin
f:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin
f:\Program Files\Microsoft Visual Studio\Common\Tools
f:\Program Files\Wise for Windows Installer
f:\Program Files\Microsoft Visual Studio\VC98\bin
f:\jdk1.3.1\bin
f:\MetaDeveloper\hcarc\bin
f:\src\psuite\main\src\buildengine
f:\bin
SysDir: F:\WINDOWS\System32
WinDir: F:\WINDOWS
CYGWIN = `nowinsymlinks tty error_start=f:\cygwin\bin\dumper.exe'
HOME = `c:\cygwin-mounts\home\pholejs'
MAKE_MODE = `unix'
PWD = `/home/pholejs/gnome/dbg/glib-2.1.4'
USER = `pholejs'
ALLUSERSPROFILE = `F:\Documents and Settings\All Users'
APPDATA = `F:\Documents and Settings\PHolejs\Application Data'
BASEMAKE = `F:\Program Files\Microsoft Platform SDK\Include\BKOffice.Mak'
BASHRC_INITED = `BASHRC_INITED'
BKOFFICE = `F:\Program Files\Microsoft Platform SDK\.'
CLASSPATH =
`f:\Gemplus\GemXpresso.rad3\lib\gse\gse_gxp211_pk.jar;f:\Gemplus\GemXpresso.rad3\lib\cryptix-gemxpresso.jar;f:\Gemplus\GemXpresso.rad3\lib\cryptix-jce-api.jar'
CLIENTNAME = `Console'
COMMONPROGRAMFILES = `F:\Program Files\Common Files'
COMPUTERNAME = `PRGPC009'
COMSPEC = `F:\WINDOWS\system32\cmd.exe'
DISPLAY = `:0.0'
DXSDKROOT = `F:\Program Files\Microsoft Platform SDK\.'
EDITOR = `nano'
HOMEDRIVE = `F:'
HOMEPATH = `\Documents and Settings\PHolejs'
IMNINST = `help'
IMNINSTSRV = `F:\IMNnq_NT'
INCLUDE = `F:\Program Files\Microsoft Platform SDK\Include;F:\Program Files\Microsoft
Platform SDK\Src\WTL\Include;F:\Program Files\Microsoft Visual
Studio\VC98\atl\include;F:\Program Files\Microsoft Visual
Studio\VC98\mfc\include;F:\Program Files\Microsoft Visual Studio\VC98\include'
INETSDK = `F:\Program Files\Microsoft Platform SDK\.'
JAVA_HOME = `F:\jdk1.3.1'
JC21_HOME = `C:\Store\Chipcards\javacard\jc211'
JDKHOME = `F:\jdk1.3.1'
LIB = `F:\Program Files\Intel\Compiler50\ia32\lib;F:\Program Files\Microsoft Platform
SDK\Lib;F:\Program Files\Microsoft Visual Studio\VC98\mfc\lib;F:\Program
Files\Microsoft Visual Studio\VC98\lib'
LOGNAME = `pholejs'
LOGONSERVER = `\\PRGOP01'
LS_COLORS =
`no=00:fi=00:di=01;34:ln=01;36:pi=47;33:so=01;35:bd=47;32;01:cd=47;32;01:or=47;31;01:ex=01;31:*.tar=31:*.tgz=31:*.taz=31:*.zip=31:*.z=31:*.Z=31:*.gz=31:*.bz2=31:*.rpm=31:*.jpg=01;35:*.png=01;35:*.gif=01;35:*.bmp=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.mpg=01;35:*.avi=01;35:*.fli=01;35:*.gl=01;35:*.dl=01;35:'
MANPATH = `:/usr/ssl/man'
MSDEVDIR = `F:\Program Files\Microsoft Visual Studio\Common\MSDev98;F:\Program
Files\Debugging Tools for Windows'
MSSDK = `F:\Program Files\Microsoft Platform SDK\.'
MSTOOLS = `F:\Program Files\Microsoft Platform SDK\.'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/home/pholejs'
OS = `Windows_NT'
P4CLIENT = `pholejs_ws'
P4PASSWD = `A265487F2507F223620AD918A903B2E9'
P4PORT = `prgop01:1666'
P4USER = `pholejs'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 4 Stepping 4, AuthenticAMD'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0404'
PROGRAMFILES = `F:\Program Files'
PS1 = `\w:'
SESSIONNAME = `Console'
SGML_CATALOG_FILES =
`./catalog:/usr/local/lib/sgml/dtd/dsssl/catalog:/usr/local/lib/sgml/dtd/html/catalog:/usr/local/lib/sgml/dtd/docbook41/docbook.cat:/usr/local/lib/sgml/stylesheets/docbook/catalog:/usr/share/xml/dtd/docbook412/docbook.cat'
SHLVL = `3'
SYSTEMDRIVE = `F:'
SYSTEMROOT = `F:\WINDOWS'
TEMP = `f:\cygwin\tmp'
TERM = `xterm'
TEXMF = `{/usr/share/lilypond/1.6.5,/usr/share/texmf}'
TMP = `f:\cygwin\tmp'
USERDNSDOMAIN = `PRGOP.PRA.ST.COM'
USERDOMAIN = `PRGOP'
USERNAME = `PHolejs'
USERPROFILE = `F:\Documents and
Re: pipe improvements in snapshot
I have similar experience. Examining the processes when the ./configure hangs reveals that hanging leaf seems to be always 'sed', running as a part of config.status script creating Makefiles etc. I'm running XPPro, the same results were achieved when running configure inside xterm or inside FSFemacs (X version). Attached is cygcheck output, but it was already running *after* I reverted to 20021209 snapshot. If someone needs cygcheck output with offending snapshot, pls let me know. Pavel P.S.: Sorry for 'me too' type of post, butI think that this can be important.. [EMAIL PROTECTED] wrote: With a Cygwin CVS tree I built this AM (2) below rxvt has problems when configuring a project from a build directory ie $TOP_DIR src build cd $TOP_DIR/build ../configure The problems vary from run to run ranging from 'error parsing uname' to program hang recoverable with 'ctrl-C' making me suspect a possible data loss Using the gcc option -pipe seems to allow the configure process Using the -pipe flag I have not seen the uname error but it does eventually hang when actually creating the Makefiles This project uses libtool With the CVS tree build (1) below I do not experience this (1) 10-Dec-2002 7:10:38a6,683,847 cygwin-20021210.tar.gz (2) 12-Dec-2002 6:09:42a6,688,318 cygwin-20021212.tar.gz The times are EST and the tarballs are created by a script that does a CVS update, make, make tarball which takes ~20 minutes so the CVS update time should be approximately 20 minutes earlier Any 'tips' as to how to best debug this appreciated Norman -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ Cygwin Win95/NT Configuration Diagnostics Current System Time: Thu Dec 12 13:42:19 2002 Windows XP Professional Ver 5.1 Build 2600 Service Pack 1 Path: f:\cygwin\usr\local\bin f:\cygwin\bin f:\cygwin\usr\X11R6\bin c:\cygwin-mounts\opt\gnome2\bin f:\bin f:\Program Files\Microsoft Platform SDK\Bin f:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin f:\Program Files\Microsoft Visual Studio\Common\Tools f:\Program Files\Wise for Windows Installer f:\Program Files\Microsoft Visual Studio\VC98\bin f:\jdk1.3.1\bin f:\MetaDeveloper\hcarc\bin f:\src\psuite\main\src\buildengine f:\bin SysDir: F:\WINDOWS\System32 WinDir: F:\WINDOWS CYGWIN = `nowinsymlinks tty error_start=f:\cygwin\bin\dumper.exe' HOME = `c:\cygwin-mounts\home\pholejs' MAKE_MODE = `unix' PWD = `/home/pholejs' USER = `pholejs' ALLUSERSPROFILE = `F:\Documents and Settings\All Users' APPDATA = `F:\Documents and Settings\PHolejs\Application Data' BASEMAKE = `F:\Program Files\Microsoft Platform SDK\Include\BKOffice.Mak' BASHRC_INITED = `BASHRC_INITED' BKOFFICE = `F:\Program Files\Microsoft Platform SDK\.' CLASSPATH = `f:\Gemplus\GemXpresso.rad3\lib\gse\gse_gxp211_pk.jar;f:\Gemplus\GemXpresso.rad3\lib\cryptix-gemxpresso.jar;f:\Gemplus\GemXpresso.rad3\lib\cryptix-jce-api.jar' COMMONPROGRAMFILES = `F:\Program Files\Common Files' COMPUTERNAME = `PRGPC009' COMSPEC = `F:\WINDOWS\system32\cmd.exe' DISPLAY = `:0.0' DXSDKROOT = `F:\Program Files\Microsoft Platform SDK\.' EDITOR = `nano' HOMEDRIVE = `F:' HOMEPATH = `\Documents and Settings\PHolejs' IMNINST = `help' IMNINSTSRV = `F:\IMNnq_NT' INCLUDE = `F:\Program Files\Microsoft Platform SDK\Include;F:\Program Files\Microsoft Platform SDK\Src\WTL\Include;F:\Program Files\Microsoft Visual Studio\VC98\atl\include;F:\Program Files\Microsoft Visual Studio\VC98\mfc\include;F:\Program Files\Microsoft Visual Studio\VC98\include' INETSDK = `F:\Program Files\Microsoft Platform SDK\.' JAVA_HOME = `F:\jdk1.3.1' JC21_HOME = `C:\Store\Chipcards\javacard\jc211' JDKHOME = `F:\jdk1.3.1' LIB = `F:\Program Files\Intel\Compiler50\ia32\lib;F:\Program Files\Microsoft Platform SDK\Lib;F:\Program Files\Microsoft Visual Studio\VC98\mfc\lib;F:\Program Files\Microsoft Visual Studio\VC98\lib' LOGNAME = `pholejs' LOGONSERVER = `\\PRGOP02' LS_COLORS = `no=00:fi=00:di=01;34:ln=01;36:pi=47;33:so=01;35:bd=47;32;01:cd=47;32;01:or=47;31;01:ex=01;31:*.tar=31:*.tgz=31:*.taz=31:*.zip=31:*.z=31:*.Z=31:*.gz=31:*.bz2=31:*.rpm=31:*.jpg=01;35:*.png=01;35:*.gif=01;35:*.bmp=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.mpg=01;35:*.avi=01;35:*.fli=01;35:*.gl=01;35:*.dl=01;35:' MANPATH = `:/usr/ssl/man' MSDEVDIR = `F:\Program Files\Microsoft Visual Studio\Common\MSDev98;F:\Program Files\Debugging Tools for Windows' MSSDK = `F:\Program Files\Microsoft Platform SDK\.' MSTOOLS = `F:\Program Files\Microsoft Platform SDK\.' NUMBER_OF_PROCESSORS = `1' OS = `Windows_NT' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 4 Stepping 4, AuthenticAMD'
Emacs hangs again (1.3.15, 20021115 and 20021119(!) snapshots)
Hello,
I'm experiencing yet another kind of hangs of emacs (running in X
window). This happens during emacs startup, but only if I resize its
window with mouse while emacs is processing startup files. Then it never
finishes its startup and eats 100% of CPU (quite similar symptoms of
previous bug fixed in 20021115 snapshot).
I've verified the same behaviour with 1.3.15-2 cygwin1 release, 20021115
and 20021119 snapshots.
strace shows this fragment, looping forever:
repeat start here
55 17683118 [main] emacs 2884 cygwin_select: 6, 0x1FB3FC, 0x0, 0x0, 0x0
56 17683174 [main] emacs 2884 dtable::select_read: /dev/streamsocket
fd 5
29 17683203 [main] emacs 2884 cygwin_select: to NULL, ms
30 17683233 [main] emacs 2884 cygwin_select: sel.always_ready 0
56 17683289 [main] emacs 2884 start_thread_socket: Handle 0x6F4
28 17683317 [main] emacs 2884 start_thread_socket: Added to readfds
135 17683452 [main] emacs 2884 start_thread_socket: exitsock 0x624
51 17683503 [main] emacs 2884 start_thread_socket: stuff_start 0x1FB2E0
58 17683561 [main] emacs 2884 select_stuff::wait: m 2, ms 4294967295
33 17683594 [main] emacs 2884 select_stuff::wait: signal received
80 17683674 [main] emacs 2884 select_stuff::cleanup: calling cleanup
routines
35 17683709 [main] emacs 2884 socket_cleanup: si 0x2051FA60
si-thread 0x610CA824
31 17683740 [main] emacs 2884 socket_cleanup: connection to
si-exitsock 0x624
315 17684055 [select_socket] emacs 2884 thread_socket: stuff_start
0x20522A84
55 17684110 [select_socket] emacs 2884 thread_socket: Win32 select
returned 2
35 17684145 [select_socket] emacs 2884 thread_socket: s 0x203B9590,
testing fd 5 (/dev/streamsocket)
33 17684178 [select_socket] emacs 2884 thread_socket: read_ready
30 17684208 [select_socket] emacs 2884 thread_socket: saw exitsock read
165 17684373 [main] emacs 2884 socket_cleanup: returning
32 17684405 [main] emacs 2884 select_stuff::~select_stuff: deleting
select records
repeated forever
Unfortunately, I'm not able to say from this whether is it a bug in
cygwin's select() internals or emacs calling it forever for some other
strange reason. I'll try to understand cygwin's select.cc code and
analyze further, but in the meanwhile, if anyone has any idea..
I've the full strace output, but it is quite big (800kB bz2). If anyone
wants it, I can post it privately.
thanks
Pavel
Cygwin Win95/NT Configuration Diagnostics
Current System Time: Tue Nov 19 13:05:51 2002
Windows XP Professional Ver 5.1 Build 2600 Service Pack 1
Path: f:\cygwin\usr\local\bin
f:\cygwin\bin
f:\cygwin\usr\X11R6\bin
c:\cygwin-mounts\opt\gnome2\bin
f:\bin
f:\Program Files\Microsoft Platform SDK\Bin
f:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin
f:\Program Files\Microsoft Visual Studio\Common\Tools
f:\Program Files\Wise for Windows Installer
f:\Program Files\Microsoft Visual Studio\VC98\bin
f:\jdk1.3.1\bin
f:\MetaDeveloper\hcarc\bin
f:\src\psuite\main\src\buildengine
f:\bin
SysDir: F:\WINDOWS\System32
WinDir: F:\WINDOWS
CYGWIN = `nowinsymlinks tty error_start=f:\cygwin\bin\dumper.exe'
HOME = `c:\cygwin-mounts\home\pholejs'
LD_LIBRARY_PATH = `\opt\kde2\lib:\opt\kde2\bin'
MAKE_MODE = `unix'
PWD = `/home/pholejs/cyg-em-bug'
USER = `pholejs'
ALLUSERSPROFILE = `F:\Documents and Settings\All Users'
APPDATA = `F:\Documents and Settings\PHolejs\Application Data'
BASEMAKE = `F:\Program Files\Microsoft Platform SDK\Include\BKOffice.Mak'
BASHRC_INITED = `BASHRC_INITED'
BKOFFICE = `F:\Program Files\Microsoft Platform SDK\.'
CLASSPATH =
`f:\Gemplus\GemXpresso.rad3\lib\gse\gse_gxp211_pk.jar;f:\Gemplus\GemXpresso.rad3\lib\cryptix-gemxpresso.jar;f:\Gemplus\GemXpresso.rad3\lib\cryptix-jce-api.jar'
CLIENTNAME = `Console'
COMMONPROGRAMFILES = `F:\Program Files\Common Files'
COMPUTERNAME = `PRGPC009'
COMSPEC = `F:\WINDOWS\system32\cmd.exe'
DISPLAY = `:0.0'
DXSDKROOT = `F:\Program Files\Microsoft Platform SDK\.'
EDITOR = `gnuclient'
HOMEDRIVE = `F:'
HOMEPATH = `\Documents and Settings\PHolejs'
IMNINST = `help'
IMNINSTSRV = `F:\IMNnq_NT'
INCLUDE = `F:\Program Files\Microsoft Platform SDK\Include;F:\Program Files\Microsoft
Platform SDK\Src\WTL\Include;F:\Program Files\Microsoft Visual
Studio\VC98\atl\include;F:\Program Files\Microsoft Visual
Studio\VC98\mfc\include;F:\Program Files\Microsoft Visual Studio\VC98\include'
INETSDK = `F:\Program Files\Microsoft Platform SDK\.'
JAVA_HOME = `F:\jdk1.3.1'
JC21_HOME = `C:\Store\Chipcards\javacard\jc211'
JDKHOME = `F:\jdk1.3.1'
KDEDIR = `/opt/kde2'
KDEHOME = `/home/pholejs/.kde2'
LIB = `F:\Program Files\Intel\Compiler50\ia32\lib;F:\Program Files\Microsoft Platform
SDK\Lib;F:\Program Files\Microsoft Visual Studio\VC98\mfc\lib;F:\Program
Files\Microsoft Visual Studio\VC98\lib'
LOGNAME = `pholejs'
LOGONSERVER = `\\PRGOP02'
LS_COLORS =
Re: XWin.exe -- xinit link
I think you are looking for $HOME/.xserverrc file. E.g. mine contains: #! /bin/sh X -nowinkill -nodecoration -lesspointer -rootless BTW, this all seems to be documented in xinit man page, as pointed out by Thomas. Pavel [EMAIL PROTECTED] wrote: Thanks Thomas, The thing is, no matter what I put in those files, it either starts XWin with a border, or not at all. And when I do get it to start up, there is always a console mode window hanging around until I close it, and that closes XWin... *sigh* I AM trying to understand how all this stuff fits together, but I'm not having very much luck. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Thomas Chadwick Sent: Sunday, November 17, 2002 10:41 PM To: [EMAIL PROTECTED] Subject: RE: XWin.exe -- xinit link RTFM! Do man xinit from the Cygwin command-line and read the 1st 3 paragraphs. From: Jean-Claude Gervais [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: XWin.exe -- xinit link Date: Sat, 16 Nov 2002 10:08:07 -0500 Thanks Artur, But that's not quite the info I was looking for; You see, when I type startxwin.bat or startxwin.sh, I get a DIFFERENT result than from starting xinit by itself. Yet, xinit does start XWin, only it is starting it in windowed mode... Which is OK, but I'm just wondering WHERE does xinit get this from? Is it executing a script? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Artur Hefczyc Sent: Saturday, November 16, 2002 9:56 AM To: [EMAIL PROTECTED] Subject: Re: XWin.exe -- xinit link What parameters does it use to start XWin? Where does it get the parameters? You can find manual and parameters for XWin from command: man XWin Is it executing a script? /usr/X11R6/bin/startxwin.bat /usr/X11R6/bin/startxwin.sh Artur Hefczyc -- Artur Hefczyc http://wttools.sf.net/ _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
Re: Q: python compiled with gcc-3.2?
Claudius, I think that your problem is that you are linking C++ dll with gcc driver. Try to use g++ also for linking, and it should work OK. Or add -lstdc++ switch ad the end of your link line (but using g++ for linking C++ modules is generally preferred). Pavel [EMAIL PROTECTED] wrote: Now, in SWIG-1.3.16/Examples/python/simple, the result of make: @PC169/.../simple$ make make -f ../../Makefile SRCS='example.c' SWIG='../../../swig' \ TARGET='example' INTERFACE='example.i' python make[1]: Entering directory `/u/schnoerr/Source/C++/Tools/SWIG-1.3.16/Examples/python/simple' ../../../swig -python example.i g++ -c example_wrap.c example.c -DHAVE_CONFIG_H -DUSE_DL_IMPORT -I/hd/schnoerr/local/Installs/Programmierung/Shells/cygwin/lib/python2.2/inc lude/python2.2 -I/hd/schnoerr/local/Installs/Programmierung/Shells/cygwin/lib/python2.2/lib /python2.2/config gcc -shared example.o example_wrap.o -L/hd/schnoerr/local/Installs/Programmierung/Shells/cygwin/lib/python2.2/lib /python2.2/config -lpython2.2 -o _example.dll example_wrap.o(.eh_frame+0x11):example_wrap.c: undefined reference to `___gxx_personality_v0' collect2: ld returned 1 exit status make[1]: *** [python] Error 1 make[1]: Leaving directory `/u/schnoerr/Source/C++/Tools/SWIG-1.3.16/Examples/python/simple' make: *** [all] Error 2 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Q. on creating DLL's for use w/ excel (export names without @0,@ 4 etc?) (cygwin 1.3.13-2)
Matthew,
1. you can try ld's option --kill-at. The link cmdline would look like this:
gcc -Wl,--kill-at -Wl,--out-implib,libfoo.import.a -mno-cygwin -shared
-o foo.dll foo.o
2. you can create .def file foo.def containing list of exported symbols
without @NN suffix (one symbol per line). Then add .def file to your
link commandline (be sure that it actually precedes all .o files).
See ld docs for more details about both approaches.
Pavel
[EMAIL PROTECTED] wrote:
I've searched on google for some references to interfacing cygwin with
win32
dll's. I've made a little progress but am kind of stuck creating DLL's
inside cygwin. The method I am using is the following:
/* foo.c */
#include
int WINAPI foobar() { return 1234; }
gcc -mno-cygwin foo.c -c
gcc -Wl,--out-implib,libfoo.import.a -mno-cygwin -shared -o foo.dll foo.o
When I look at the DLL file with MSVC's depends.exe I see the symbol is
foobar@0 -- and I guess the @0 refers to how many bytes the function
args
take (I get @4 with a pointer to double, etc.). The only way I can
make the
symbols available to excel's visual basic interface is to cheat and
hexedit
foo.dll to change foobar@0 to foobarX0. Then I can put a few lines
in my
excel modules like
Declare Function foobarX0 Lib e:\dlltest\foo.dll () As Integer
Function MattVersion()
Dim i As Integer
i = foobarX0()
MattVersion = MW 0.0.1.0.1. + Str(i)
End Function
Surely there is a better way. Can anyone suggest a better technique?
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Another problem using GDB
Cygwin normally does not produce core dumps, but only simple textual stack backtraces (try to look at gtl.exe.stackdump using your text editor). However, you can have full core dumps using dumper utility; see http://cygwin.com/cygwin-ug-net/using-utils.html#DUMPER for details. Pavel [EMAIL PROTECTED] wrote: I'm having another problem with GDB. Normally, one would debug a core file as follows (correct?): gdb -nw gtl.exe gtl.exe.stackdump Unfortunately, I get the following in response: GNU gdb 5.0 (20010428-3) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-cygwin... /home/w/src/gtl/gtl.exe.stackdump is not a core dump: File format not recognized (gdb) Is this an operator error? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
