Re: [ITP] logiweb-0.2.9
Hi Klaus, On May 10 14:54, Klaus Grue wrote: http://logiweb.eu/1.0/doc/download/cygwin/dist/logiweb/setup.hint http://logiweb.eu/1.0/doc/download/cygwin/dist/logiweb/logiweb-0.2.9-1.tar.bz2 http://logiweb.eu/1.0/doc/download/cygwin/dist/logiweb/logiweb-0.2.9-1-src.tar.bz2 # setup.hint file for the Logiweb package for CYGWIN sdesc: a system for electronic distribution of mathematics ldesc: Logiweb allows to web publish 'Logiweb pages', i.e. journal quality articles which contain machine readable objects like programs, testsuites, definitions, axioms, lemmas, and proofs. Among other, Logiweb is suited for literate programming and for publication of machine verified proofs. Logiweb allows Logiweb pages to reference previously published Logiweb pages such that programs on a page may call programs on referenced pages, proofs on a page may reference lemmas on referenced pages, and so on. category: Devel requires: Cygwin gcc tetex tetex-base tetex-extra make perl vim bzip2 diffutils man which Your package looks basically good with two small exceptions: - The binaries lgc and lgwam.exe are both in /bin. However, the lgc script expects lgwam.exe to be in /usr/bin. While that doesn't matter in a Cygwin default installation it's a bit unclean and *might* break something. I'd suggest to repackage so that the binaries are in /usr/bin. - The setup.hint file is not quite ok. - The requires line in setup.hint contains Cygwin. This should be removed since it's an automatic dependency anyway. Above all, the Cygwin package is called cygwin in all lower case. - The dependencies are not clear to me and seem a bit over the top. The lgwam.exe binary depends on libgcc1, not on gcc as a whole. The tetex dependencies I can understand. But why a dependency to make? And why to vim? You can't assume that a user uses vim as the editor of choice. And how can a package actually depend on which? While make is at least required to build the examples, I don't see any real requirement for perl, vim, or which. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: RFU: mercurial-1.5.2
On May 11 18:50, Jari Aalto wrote: New upstream release wget \ http://cante.net/~jaalto/tmp/cygwin/mercurial/mercurial-1.5.2-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/mercurial/mercurial-1.5.2-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/mercurial/setup.hint Uploaded. Can the 1.4 versions be removed? Did you see http://cygwin.com/ml/cygwin-apps/2010-05/msg00033.html ? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Updated package: brltty 4.1-1
On May 13 00:46, Samuel Thibault wrote: Hello, There is a new version 4.2-1 of brltty, please upload http://brl.thefreecat.org/brltty/cygwin/brltty-4.2-1-src.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/brltty-4.2-1.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/setup.hint http://brl.thefreecat.org/brltty/cygwin/libbrlapi-devel/libbrlapi-devel-4.2-1.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/libbrlapi/libbrlapi-4.2-1.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/python-brlapi/python-brlapi-4.2-1.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/tcl-brlapi/tcl-brlapi-4.2-1.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/xbrlapi/xbrlapi-4.2-1.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/java-brlapi/java-brlapi-4.2-1.tar.bz2 and please keep version 4.1-1 as old. Uploaded and all versions prior to 4.1-1 removed. I also changed setup.hint so that the requires line does not refer to cygwin anymore. Please change that locally. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Updated package: brltty 4.1-1
On May 26 11:08, Corinna Vinschen wrote: On May 13 00:46, Samuel Thibault wrote: Hello, There is a new version 4.2-1 of brltty, please upload http://brl.thefreecat.org/brltty/cygwin/brltty-4.2-1-src.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/brltty-4.2-1.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/setup.hint http://brl.thefreecat.org/brltty/cygwin/libbrlapi-devel/libbrlapi-devel-4.2-1.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/libbrlapi/libbrlapi-4.2-1.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/python-brlapi/python-brlapi-4.2-1.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/tcl-brlapi/tcl-brlapi-4.2-1.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/xbrlapi/xbrlapi-4.2-1.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/java-brlapi/java-brlapi-4.2-1.tar.bz2 and please keep version 4.1-1 as old. Uploaded and all versions prior to 4.1-1 removed. I also changed setup.hint so that the requires line does not refer to cygwin anymore. Please change that locally. Btw., did you see http://cygwin.com/ml/cygwin-apps/2010-05/msg00033.html ? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] logiweb-0.2.9
Hi Corinna, http://logiweb.eu/1.0/doc/download/cygwin/dist/logiweb/setup.hint http://logiweb.eu/1.0/doc/download/cygwin/dist/logiweb/logiweb-0.2.9-1.tar.bz2 http://logiweb.eu/1.0/doc/download/cygwin/dist/logiweb/logiweb-0.2.9-1-src.tar.bz2 # setup.hint file for the Logiweb package for CYGWIN sdesc: a system for electronic distribution of mathematics ldesc: Logiweb allows to web publish 'Logiweb pages', i.e. journal quality articles which contain machine readable objects like programs, testsuites, definitions, axioms, lemmas, and proofs. Among other, Logiweb is suited for literate programming and for publication of machine verified proofs. Logiweb allows Logiweb pages to reference previously published Logiweb pages such that programs on a page may call programs on referenced pages, proofs on a page may reference lemmas on referenced pages, and so on. category: Devel requires: Cygwin gcc tetex tetex-base tetex-extra make perl vim bzip2 diffutils man which Your package looks basically good with two small exceptions: Thanks for looking at it - The binaries lgc and lgwam.exe are both in /bin ... I'd suggest to repackage so that the binaries are in /usr/bin. OK - The setup.hint file is not quite ok. - The requires line in setup.hint contains Cygwin. This should be removed ... OK - The dependencies are not clear to me and seem a bit over the top. Agreed. What shall I include? These are the dependencies: Runtime: gcc tetex tetex-base tetex-extra Build:make perl vim bzip2 diffutils Tutorial: man which The system does execl(gcc), so it *really* needs gcc at runtime, c.f. https://bugzilla.redhat.com/show_bug.cgi?id=584729 Bug 584729 - logiweb must require gcc The dependency to vim is annoying. But it seems to be the only way to get the xxd utility which is needed for building the package from source. man and which are just needed if doing the tutorial at http://logiweb.eu Runtime, build, and tutorial dependencies are stated in the README. Is gcc tetex tetex-base tetex-extra the right list of dependencies for setup.hint? Cheers, Klaus
Re: [ITP] logiweb-0.2.9
On May 26 12:28, Klaus Grue wrote: Hi Corinna, - The dependencies are not clear to me and seem a bit over the top. Agreed. What shall I include? These are the dependencies: Runtime: gcc tetex tetex-base tetex-extra Build:make perl vim bzip2 diffutils Tutorial: man which The system does execl(gcc), so it *really* needs gcc at runtime, c.f. https://bugzilla.redhat.com/show_bug.cgi?id=584729 Bug 584729 - logiweb must require gcc The dependency to vim is annoying. But it seems to be the only way to get the xxd utility which is needed for building the package from source. man and which are just needed if doing the tutorial at http://logiweb.eu Runtime, build, and tutorial dependencies are stated in the README. Is gcc tetex tetex-base tetex-extra the right list of dependencies for setup.hint? Yes, but not quite. Only the runtime dependencies should be mentioned here, but gcc is sort of a problem. Are you referring to gcc 3 or gcc 4? Since you built with gcc4 and since gcc4 is the standard compiler for Cygwin you should better require the gcc4 package, I guess. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] logiweb-0.2.9
Hi Corinna, Is gcc tetex tetex-base tetex-extra the right list of dependencies for setup.hint? Yes, but not quite. Only the runtime dependencies should be mentioned here, but gcc is sort of a problem. Are you referring to gcc 3 or gcc 4? Since you built with gcc4 and since gcc4 is the standard compiler for Cygwin you should better require the gcc4 package, I guess. OK - thanks - I'll repackage, test, and resubmit asap - Klaus
Attn: Dave Korn - Re: setup.exe packagedb cache refresh bug
On Sat, May 22, 2010 at 12:57:25PM -0400, Christopher Faylor wrote: On Sat, May 22, 2010 at 08:52:29AM -0700, Brendan Conoboy wrote: On 05/21/2010 11:18 PM, Christopher Faylor wrote: This comment in RootPage::OnNext would suggest that this was already supposed to have been handled. /* Deferred initialization of packagedb *after* the root dir has been chosen. */ It appears you're looking at rev 2.25 of root.cc, while I'm looking at the latest, 2.26 which doesn't have that. Dave Korn's changelog entry: 2010-04-17 Dave Korn dave.korn.cyg...@gmail.com * root.cc (RootPage::OnNext): Don't construct a packagedb here nor do deferred initialisation of static packagedb::task. * source.cc (save_dialog): Don't construct a packagedb here, and set static packagedb::task directly instead of chosen_db_task. * package_meta.cc (packagemeta::action_caption): Don't bother to construct a packagedb here, just access packagedb::task directly. * package_db.cc: Move 'static members' comment near static members. (chosen_db_task): Delete. * package_db.h (chosen_db_task): Don't declare extern. (packagedb): Extend comments on class. Presumably this has caused the problem. Dave, what was the goal of this patch? The archives are your friend. http://cygwin.com/ml/cygwin-apps/2010-04/threads.html#00037 Dave, it looks like your recent change broke this. Do you have any suggestions for fixing it? cgf
Re: Updated package: brltty 4.1-1
On 2010-05-26 05:38, Samuel Thibault wrote: Well, no and yes. I hadn't noticed that mail in particular, but I'm aware we'll switch to python2.6 and I know that python-brlapi and python-pyrex work with python2.6. I'm however not sure to understand what I'm supposed to do: should I keep providing a 2.6-built version of the packages somewhere so that on 31st all the python packages can be updated at the same time? Yes, you should have a 2.6-built version of your packages ready for upload, and let us know where as soon as they are ready. Yaakov
[RFU] rdiff-backup 1.2.8-4
This is a test release built against Python 2.6. Please leave 1.2.8-3 as curr and 1.2.8-2 as prev. wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/rdiff-backup/rdiff-backup-1.2.8-4-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/rdiff-backup/rdiff-backup-1.2.8-4.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/rdiff-backup/setup.hint -- David Rothenberger daver...@acm.org God requireth not a uniformity of religion. -- Roger Williams
[RFU] subversion-1.6.11-2
This is a test version build against Python 2.6. Please leave 1.6.11-1 as curr and 1.6.9-2 as prev. wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-1.6.11-2-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-1.6.11-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-apache2/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-apache2/subversion-apache2-1.6.11-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-devel/subversion-devel-1.6.11-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-perl/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-perl/subversion-perl-1.6.11-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-python/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-python/subversion-python-1.6.11-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-ruby/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-ruby/subversion-ruby-1.6.11-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-tools/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-tools/subversion-tools-1.6.11-2.tar.bz2 -- David Rothenberger daver...@acm.org God requireth not a uniformity of religion. -- Roger Williams
Re: [ITP] logiweb-0.2.9
Hi Corinna, # setup.hint file for the Logiweb package for CYGWIN sdesc: a system for electronic distribution of mathematics ... Your package looks basically good with two small exceptions ... Thanks. The following seems to solve the issues. http://logiweb.eu/1.0/doc/download/cygwin/dist/logiweb/setup.hint http://logiweb.eu/1.0/doc/download/cygwin/dist/logiweb/logiweb-0.2.10-1.tar.bz2 http://logiweb.eu/1.0/doc/download/cygwin/dist/logiweb/logiweb-0.2.10-1-src.tar.bz2 Cheers, Klaus
Re: Cannot start xterm
I have the same problem. I reviewed the startxwin man page with no luck. Any pointers would be much appreciated. Thanks! Atul Paul Loewenstein wrote: See startxwin(.exe) man page. Run startxwin from a login shell. Paul Ryan Mcdowell (rymcdowe) wrote: Please ignore this email, anti-virus was killing some of the installation scripts :( -Original Message- From: Ryan Mcdowell (rymcdowe) Sent: Thursday, January 07, 2010 4:46 PM To: 'cygwin-xfree@cygwin.com' Subject: RE: Cannot start xterm My hard drive crashed and I reinstalled XP SP3 from scratch. I then installed cygwin 1.7.3 from scratch. My first issue was I could not find startxwin.bat. I know it was supposed to be moved to /bin/startxwin.bat, but its not there. I built my own shortcut to start xwin C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe. That seems to start up the server just fine. However, when I click on Applications-xterm, nothing happens. I started up a normal cygwin window and manually try to start xterm via xterm -display localhost:0. This gives me the following: bash-3.2$ xterm -display localhost:0 Warning: Cannot convert string -adobe-helvetica-boldo8859-* to type FontStruct Warning: Unable to load any usable ISO8859 font Warning: Unable to load any usable ISO8859 font Error: Aborting: no font found bash-3.2$ I then tried to install all the fonts I could find, nothing seemed to fix the issue. I should also point out that I think something else was dorked up in the installation, as the PATH variable failed to include basic things like /bin. I had to manually add them back in my .bashrc (which the Cygwin.bat script fails to read, so I have to manually source it). When I first run Cygwin.bat, here is my environment. I'm thinking maybe some other variable is not set properly which is the root cause of xterm not finding any fonts. bash-3.2$ /bin/printenv HOMEPATH=\Documents and Settings\rymcdowe APPDATA=C:\Documents and Settings\rymcdowe\Application Data TERM=cygwin PROCESSOR_IDENTIFIER=x86 Family 6 Model 14 Stepping 12, GenuineIntel WINDIR=C:\WINDOWS USERDOMAIN=CISCO OS=Windows_NT ALLUSERSPROFILE=C:\Documents and Settings\All Users !::=::\ TEMP=/cygdrive/c/DOCUME~1/rymcdowe/LOCALS~1/Temp DEFLOGDIR=C:\Documents and Settings\All Users\Application Data\McAfee\DesktopProtection COMMONPROGRAMFILES=C:\Program Files\Common Files QTJAVA=C:\Program Files\QuickTime\QTSystem\QTJava.zip USERNAME=rymcdowe PROCESSOR_LEVEL=6 PATH=/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/system32/WindowsPowerShell/v1.0:/cygdrive/c/ProgramFiles/Credant/Shieldv5.4.2/:/cygdrive/c/ProgramFiles/QuickTime/QTSystem/:/cygdrive/c/ProgramFiles/Intel/WiFi/bin/ FP_NO_HOST_CHECK=NO PWD=/usr/bin SYSTEMDRIVE=C: USERPROFILE=C:\Documents and Settings\rymcdowe LOGONSERVER=\\ADC-RTP1-C1-5-W PROCESSOR_ARCHITECTURE=x86 !C:=C:\cygwin\bin SHLVL=1 HOME=/home/rymcdowe USERDNSDOMAIN=CISCO.COM PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1 HOMEDRIVE=C: PROMPT=$P$G COMSPEC=C:\WINDOWS\system32\cmd.exe TMP=/cygdrive/c/DOCUME~1/rymcdowe/LOCALS~1/Temp SYSTEMROOT=C:\WINDOWS PROCESSOR_REVISION=0e0c CLASSPATH=.;C:\Program Files\QuickTime\QTSystem\QTJava.zip PROGRAMFILES=C:\Program Files NUMBER_OF_PROCESSORS=2 VSEDEFLOGDIR=C:\Documents and Settings\All Users\Application Data\McAfee\DesktopProtection SESSIONNAME=Console COMPUTERNAME=RYMCDOWE-WXP _=/bin/printenv Anybody have any ideas? Ryan McDowell Systems Engineer Cisco Systems, Inc (W) +1 703.484.0040 (M) +1 703.201.5742 PGP Fingerprint: EED9 192F 9F45 FAE4 F6A3 8764 FEE1 299D 1B62 A361 -- 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/ -- 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/ -- View this message in context: http://old.nabble.com/RE%3A-Cannot-start-xterm-tp27067554p28686210.html Sent from the cygwin-xfree mailing list archive at Nabble.com. -- 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/
src/winsup/cygwin ChangeLog nlsfuncs.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-05-26 11:36:17 Modified files: winsup/cygwin : ChangeLog nlsfuncs.cc Log message: * nlsfuncs.cc (__set_lc_time_from_win): Use LOCALE_SMONTHNAME1 instead of LOCALE_SABBREVMONTHNAME1 in Japanese and Korean locales to get abbreviated month names. Explain why. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4942r2=1.4943 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/nlsfuncs.cc.diff?cvsroot=srcr1=1.31r2=1.32
src/winsup/cygwin ChangeLog fhandler.h fhandle ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-05-26 13:10:55 Modified files: winsup/cygwin : ChangeLog fhandler.h fhandler_tty.cc Log message: * fhandler.h (class fhandler_pty_master): Add master_thread member. * fhandler_tty.cc (fhandler_pty_master::close): Properly detach from master thread. (fhandler_pty_master::setup): Store cygthread pointer of pty master control thread in master_thread. Don't zap thread handle. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4943r2=1.4944 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler.h.diff?cvsroot=srcr1=1.400r2=1.401 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_tty.cc.diff?cvsroot=srcr1=1.201r2=1.202
src/winsup/cygwin ChangeLog include/inttypes.h
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-05-26 13:37:49 Modified files: winsup/cygwin : ChangeLog winsup/cygwin/include: inttypes.h Log message: * include/inttypes.h: Change PTR definitions to int to align with the stdint.h type definitions of intptr_t/uintptr_t. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4944r2=1.4945 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/inttypes.h.diff?cvsroot=srcr1=1.4r2=1.5
src/winsup/cygwin ChangeLog path.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-05-26 14:24:49 Modified files: winsup/cygwin : ChangeLog path.cc Log message: * path.cc (symlink_info::check): Don't try to handle remote reparse points as symlinks. Explain why. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4945r2=1.4946 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.cc.diff?cvsroot=srcr1=1.591r2=1.592
winsup/cygwin ChangeLog hires.h times.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2010-05-26 14:48:18 Modified files: cygwin : ChangeLog hires.h times.cc Log message: * hires.h (hires_base::reset): New function. (hires_us): Specify that hires_base is a public import. (hires_ms): Ditto. * times.cc (gtod): Move earlier in file. (settimeofday): Reset gtod so that base will be subsequently recalculated. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.4946r2=1.4947 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/hires.h.diff?cvsroot=uberbaumr1=1.14r2=1.15 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/times.cc.diff?cvsroot=uberbaumr1=1.100r2=1.101
src/winsup/cygwin ChangeLog fhandler_registry.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-05-26 16:58:44 Modified files: winsup/cygwin : ChangeLog fhandler_registry.cc Log message: * fhandler_registry.cc (multi_wcstombs): New function. (fhandler_registry::fstat): Call multi_wcstombs for strings of type REG_MULTI_SZ. (fhandler_registry::fill_filebuf): Ditto. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4947r2=1.4948 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_registry.cc.diff?cvsroot=srcr1=1.59r2=1.60
Re: Encounter undefined reference to `_libintl_dgettext'
Hi, after adding in the 'LDFLAGS=-lintl', i am encountering this issue with the camlibs for adc. Any idea what is the issue for this? adc65/.libs/adc65.o: In function `adc65_exchange': /home/S-SATORU/libgphoto2-2.4.3/camlibs/adc65/adc65.c:51: undefined reference to Â*`_gp_port_write' adc65/.libs/adc65.o: In function `file_list_func': /home/S-SATORU/libgphoto2-2.4.3/camlibs/adc65/adc65.c:81: undefined reference to Â*`_gp_log' adc65/.libs/adc65.o: In function `get_file_func': /home/S-SATORU/libgphoto2-2.4.3/camlibs/adc65/adc65.c:101: undefined reference to `_gp_log' /home/S-SATORU/libgphoto2-2.4.3/camlibs/adc65/adc65.c:111: undefined reference to `_gp_port_read' /home/S-SATORU/libgphoto2-2.4.3/camlibs/adc65/adc65.c:177: undefined reference to `_gp_log' adc65/.libs/adc65.o: In function `camera_init': /home/S-SATORU/libgphoto2-2.4.3/camlibs/adc65/adc65.c:261: undefined reference to `_gp_port_set_timeout' /home/S-SATORU/libgphoto2-2.4.3/camlibs/adc65/adc65.c:265: undefined reference to `_gp_port_get_settings' /home/S-SATORU/libgphoto2-2.4.3/camlibs/adc65/adc65.c:271: undefined reference to `_gp_port_set_settings' /home/S-SATORU/libgphoto2-2.4.3/camlibs/adc65/adc65.c:62: undefined reference to `_gp_log' /home/S-SATORU/libgphoto2-2.4.3/camlibs/adc65/adc65.c:72: undefined reference to `_gp_log' adc65/.libs/adc65.o: In function `adc65_exchange': /home/S-SATORU/libgphoto2-2.4.3/camlibs/adc65/adc65.c:54: undefined reference to `_gp_port_read' Dave Korn-9 wrote: On 25/05/2010 12:15, aldray wrote: Hi all, I encounter some issue when installing gphoto on cygwin. Anyone knows how to resolve this? Adding 'LDFLAGS=-lintl' at configure time should do it. cheers, DaveK -- 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 -- View this message in context: http://old.nabble.com/Encounter-undefined-reference-to-%60_libintl_dgettext%27-tp28667111p28677050.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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
bltty-4.1-1, w32api-3.14-1 and task-1.8.4-1 not installable by setup
Hi The following packages show up each time when downloading with setup but do NOT show up in the install dialog: bltty-4.1-1 and it's siblings w32api-3.14-1 task-1.8.4-1 Anybody seeing this ? Ciao Volker -- 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
1.7.5-1: problem with settimeofday() gettimeofday()
Hello. It seems that I found a problem with settimeofday() and
gettimeofday() calls in a single context. The problem is that if we
set a new time with settimeofday() call it completes succefully and
system time is updated. But then if we try to get current time with
gettimeofday() call it returns old time!
The following example could be used:
#include stdio.h
#include sys/time.h
int main(int argc, char* argv[])
{
struct timeval tv;
struct tm time_to_set;
// Get current date time since Epoch.
if (gettimeofday(tv, NULL) != 0)
{
printf(Cannot get current date time since Epoch.);
}
// Calculate local time.
if (localtime_r(tv.tv_sec, time_to_set) != time_to_set)
{
printf(Cannot convert file time to local file time.);
}
printf(Old time: %d.%d.%d - %d:%d:%d\r\n, time_to_set.tm_year +
1900, time_to_set.tm_mon + 1, time_to_set.tm_mday,
time_to_set.tm_hour, time_to_set.tm_min, time_to_set.tm_sec);
time_to_set.tm_hour = 20;
time_to_set.tm_min = 33;
time_to_set.tm_sec = 11;
time_to_set.tm_year = 2010 - 1900;
time_to_set.tm_mon = 1;
time_to_set.tm_mday = 4 + 1;
// Make new system time.
if ((tv.tv_sec = mktime(time_to_set)) == (time_t)-1)
{
printf(Cannot convert system time);
}
tv.tv_usec = 0;
// Set new system time.
if (settimeofday(tv, NULL) != 0)
{
printf(Cannot set system time);
}
// Get current date time since Epoch.
if (gettimeofday(tv, NULL) != 0)
{
printf(Cannot get current date time since Epoch.);
}
// Calculate local time.
if (localtime_r(tv.tv_sec, time_to_set) != time_to_set)
{
printf(Cannot convert file time to local file time.);
}
printf(New time (2010.2.5 - 20:33:11): %d.%d.%d - %d:%d:%d\r\n,
time_to_set.tm_year + 1900, time_to_set.tm_mon + 1,
time_to_set.tm_mday, time_to_set.tm_hour, time_to_set.tm_min,
time_to_set.tm_sec);
return 0;
}
In my case the output is:
Old time: 2010.5.26 - 12:47:23
New time (2010.2.5 - 20:33:11): 2010.5.26 - 12:47:23
--
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: brltty 4.2-1
Version 4.2-1 of brltty has been uploaded. It is a background process (daemon) providing access to the Windows Console for a blind person using a refreshable braille display. -- brltty-4.2-1 -- 2010-05-12 --- New upstream version. If you have questions or comments, please send them to the Cygwin mailing list at: cygwin@cygwin.com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: C program compilation. Needed .dll's for .exe.
On Wed, May 26, 2010 at 03:39, Kaylan wrote: OS: Windows 7 cygwin installation: Basic C/C++ compilation,debug,link,make,ect I have searched all over for answers and have came up with nothing. When i compile a C program i now know i need to include some .dll's with the .exe in order for it to run on a remote machine. At least thats been the case so far. I used the command cygcheck to see what .dll's i need to include with my .exe and i get this big list. So my question(s) is, Do i really need to include all those .dll's? Is there anyway to make the .exe independent? Are there any shortcuts to manually including all those .dll's in a distribution folder with the .exe? Short Answer: No. Although you can compile statically most of the libs, cygwin1.dll is not possible to include in the executable. There are technical reasons, and also licencing reasons. Please see: http://cygwin.com/faq/faq-nochunks.html#faq.programming.static-linking What about simply including the cygwin setup with my software? Then what would need to be installed on the remote machine to simply RUN applications compiled with cygwin? You don't need necessarily to distribute the setup.exe, or build a cygwin package. You can do as probably you already are doing: gather the needed Dll's (only those specific to Cygwin, of course), join the .exe, and include the source, (as this is required by the licencing), and just drop it together in a directory on the client PC's. Any help what so ever is greatly appreciated. Regards, ___ Julio Costa -- 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: strftime %b is broken on ja_JP locale
On May 17 21:19, Corinna Vinschen wrote: On May 15 11:39, Kazuhiro Fujieda wrote: On Fri, 14 May 2010 21:27:16 +0200 Corinna Vinschen said: It should return 5\u6708 in Japanese and 5\uc6d4 in Korea. MSDN in Japanese describes so. It, however, returns 5 in both locales. Can you please tell us the number of the knowledge base article saying so? There is only a Japanese article: http://msdn.microsoft.com/ja-jp/library/cc422084.aspx Thanks for the URL. It's incredible that such important information is not available in English. Does this really only affect the lcids 411 and 412? As far as I know, Yes. Ok, I'll apply your patch as soon as I'm back to work in a couple of days. I applied a somewhat different version of the patch. I moved the conditional out of the loop, changed the reference to the numerical lcids into MAKELANGID statements and added a comment. It works for me. Please test it as well. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Reading /proc/registry/... returns extra char
On May 13 15:38, Nellis, Kenneth wrote: From: Dale Stimson Sent: Thursday, May 13, 2010 14:13 To: cygwin@cygwin.com Subject: Reading /proc/registry/... returns extra char Reading a file under /proc/registry returns an extra character at the end, which appears to be the null character. This has happened for every registry entry that I have tried. Here is one in particular: $ cat a.dat /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Syst emBootDevice This trailing NUL character was always there, already with Cygwin 1.5. It's part of the file content. If strings are stored with a trailing NUL in a file, you don't want Cygwin to remove it for you, right? Not only that, but if you pipe that output to another process, you (or should I say I) get a stack dump: I can't observe this when using CVS HEAD. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: vfork always fail problem
On May 20 11:43, Huang Bambo wrote: 2010/5/20 Huang Bambo bambo.hu...@gmail.com: Huang, you - as the person who first saw and documented the problem in public (thank you!) - are in the best position to test it, if you can recreate the original situation (with the GBK(?) directory names). It would be beneficial to all of us, and you would be doing everybody a favour (if you wish, which is your choice), if you could test if the problem reproduces with Cygwin 1.7.5, and goes away with the snapshot. fork() now work well but find new problem after use the 0518 patch. Usually I use mintty to as the default term tool. After use this patch, I can't directly use mintty to open the first shell( like nothing happened), I must use Cygwin.bat to create a fist shell, then use short cut of mintty in the start menu to open others. I'll find out why if I have time. terminate while calling forkpty(). I'm using mintty with the latest from CVS and I can't reproduce this. Mintty starts just fine from a shortcut with target C:\cygwin\bin\mintty.exe -. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: vfork always fail problem
On May 19 00:07, Kazuhiro Fujieda wrote: On Tue, 18 May 2010 10:31:36 -0400 Christopher Faylor said: 2010-05-18 Kazuhiro Fujida fuji...@acm.org I mistyped my name in ChangeLog. Please correct Fujida to Fujieda on the first opportunity. Done. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: [ ATTN: gnupg maintainer ] error building gnupg-1.4.9-2 sources
2010/5/25, David Sastre ONTAGA at gmail dot com:
Hello,
Trying to build gnupg-1.4.9-2 from the distributed sources fails throwing:
gpgkeys_curl.c:304: error: ‘typeof’ applied to a bit-field
(full output attached)
Here are some references regarding this specific error².
Since the cygport file uses ${P} to describe URLs, I've reused it (and
*cygwin.patch file, just to avoid cygport errors) to fetch and build
latest upstream version² without problems.
Regards.
¹ http://lists.gnupg.org/pipermail/gnupg-devel/2008-April/024344.html
http://bugs.sourcemage.org/show_bug.cgi?id=14446
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486250
https://bugs.g10code.com/gnupg/issue954
² ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.10.tar.bz2
Apparently, this message never made it to the list.
(http://cygwin.com/ml/cygwin/2010-05)
I'm, therefore, re-sending it.
Regards.
--
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: 1.7.5-1: problem with settimeofday() gettimeofday()
Hello. It seems that I found a problem with settimeofday() and gettimeofday() calls in a single context. The problem is that if we set a new time with settimeofday() call it completes succefully and system time is updated. But then if we try to get current time with gettimeofday() call it returns old time! I've looked into 'times.cc' and found that 'hires_ms gtod' timer (which is used in gettimeofday()) is not reset with 'hires_ms::prime()' in settimeofday() after system call to Win32 API SetSystemTime() function! I think this is the reason of described behaviour. -- 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: Reading /proc/registry/... returns extra char
From: Corinna Vinschen Sent: Wednesday, May 26, 2010 07:48 To: cygwin@cygwin.com Subject: Re: Reading /proc/registry/... returns extra char On May 13 15:38, Nellis, Kenneth wrote: From: Dale Stimson Sent: Thursday, May 13, 2010 14:13 To: cygwin@cygwin.com Subject: Reading /proc/registry/... returns extra char Reading a file under /proc/registry returns an extra character at the end, which appears to be the null character. This has happened for every registry entry that I have tried. Here is one in particular: $ cat a.dat /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Syst emBootDevice This trailing NUL character was always there, already with Cygwin 1.5. It's part of the file content. If strings are stored with a trailing NUL in a file, you don't want Cygwin to remove it for you, right? Not only that, but if you pipe that output to another process, you (or should I say I) get a stack dump: I can't observe this when using CVS HEAD. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat CVS HEAD? Whatever; head is a red herring; the problem was reproducible by piping stdout of that registry reference to any process. I say was because I can't reproduce it now, although it was reliably reproducible then. (What's up with that?) --Ken Nellis
Re: pty infinite master control thread spawning problem
Hi Dave,
On May 18 15:14, Dave Korn wrote:
Hi,
I'm having trouble with the latest changes to the pty control code. In my
case they manifest when I run parallel make -j check on GCC; after a minute
or two all the expect processes end up spinning CPU and everything grinds to a
halt.
[...]
- 32 threads all stuck in WFSO with no useful backtrace, and one that is
frantically looping in cygthread::callfunc() at this point:
if (issimplestub)
{
/* Wait for main thread to assign 'h' */
while (!h)
yield ();
... with h never getting set.
The attached testcase demonstrates the underlying problem.
I applied a patch to CVS. It worked for me, but while testing I
encountered a handle leak in your testcase and, naturally, I thought
it's my code. After some tinkering it turned out that your parent
process neglects to wait for the child process. Adding
int status;
waitpid (child_pid, status, 0);
to the parent code removed the handle leak. Please test the change in
Cygwin if it fixes the original problem for you.
Thanks for the report and, especially, the testcase,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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-1.7.5: intptr_t/uintptr_t types and PRI?PTR/SCI?PTR format specfiers are inconsistent
On May 24 14:19, Matthew Fluet wrote: /usr/include/stdint.h typedefs intptr_t as int and uintptr_t as unsigned int. /usr/include/inttypes.h #defines PRIdPTR as ld and PRIoPTR as lo. These and the other PRI?PTR and SCN?PTR format specifiers are meant to be used for the intptr_t and uintptr_t types (thus, making them usable without needing to know their exact type definitions). This inconsistency leads to warnings from gcc. (There is also a potential calling-convention mismatch, though not on x86.) intptr_t and uintptr_t in stdint.h have been changed back in 2009 to avoid some inconsistencies with the original definition. Unfortunaltey we missed out on inttypes.h. I checked in a fix. Thanks for the report, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Reading /proc/registry/... returns extra char
Greetings, Corinna Vinschen! $ cat a.dat /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Syst emBootDevice This trailing NUL character was always there, already with Cygwin 1.5. It's part of the file content. If strings are stored with a trailing NUL in a file, you don't want Cygwin to remove it for you, right? Wrong. The training NULL is a string value terminator for REG_SZ variables, also a string separator for REG_MULTI_SZ ones. (Which ends with a spare NULL) It must not be exposed to the user. Seriously, when you are working with NULL-terminated strings, do you print the NULL to the user? Or, more specifically, can you ever reach it using string functions in first place? No, only using direct memory access you can discover the NULL at the end of a string. BTW, get it as a bugreport - reading REG_MULTI_SZ from /proc/registry returns only first string. REGEDIT4 [HKEY_CURRENT_USER\Software\ACB] test=hex(7):61,73,64,61,73,64,00,61,61,73,61,64,73,00,00 $ cat /proc/registry/HKEY_CURRENT_USER/Software/ACB/test asdasd -- WBR, Andrey Repin (anrdae...@freemail.ru) 26.05.2010, 17:31 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: 1.7.5-1: problem with settimeofday() gettimeofday()
On Wed, May 26, 2010 at 04:02:45PM +0300, ??? ?? wrote: Hello. It seems that I found a problem with settimeofday() and gettimeofday() calls in a single context. The problem is that if we set a new time with settimeofday() call it completes succefully and system time is updated. But then if we try to get current time with gettimeofday() call it returns old time! I've looked into 'times.cc' and found that 'hires_ms gtod' timer (which is used in gettimeofday()) is not reset with 'hires_ms::prime()' in settimeofday() after system call to Win32 API SetSystemTime() function! I think this is the reason of described behaviour. That sounds right. I'll check in a fix shortly. 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: False alarm about exception C0000005
On 26 May 2010 05:17, Dave Korn dave.korn.cyg...@gmail.com wrote: On 25/05/2010 12:47, Magnus Reftel wrote: Hi all, I discovered that the problem does not only affect Cygwin. It was just that I did not have any large binaries outside cygwin. Large executables built using VS Express also crash with the same exception. I guess the IT department installed some broken crap on our machines again. Sorry for the confusion! I had just about reached the same conclusion. The limit to an executable size on my machine was somewhere between 542048077 and 542048589 bytes, and the only failure mode I observed was a proper error message from bash: $ ./big.exe bash: ./big.exe: Cannot allocate memory So, I reckon you probably have some interfering BLODA, maybe a DLL that is injected into all processes and tries to allocate some memory at startup or something like that and doesn't handle a failure well. That seems to be correct. In the failing case (when compiled with VS), the VS debugger lists ntdll.dll and kernel32.dll being loaded before the crash, and when the executable does not crash, sysfer.dll and msvcr100d.dll are also loaded. sysfer is a Symantec DLL. Should have guessed it... Anyway, thanks for looking at this and sorry to have wasted your time! Best Regards Magnus Reftel -- 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 1.7: Accessing (local) junctions via SMB
On May 18 09:11, Mario Küchler wrote: Hi, there seems to be a change from 1.5 to 1.7 when processing junctions (reparse points). This was already discussed here but I want to point to an issue when accessing them via SMB. Both hosts have a local junction from d:\temp to c:\temp. SMB connection goes from host1 to host2 (identical account, using admin shared like c$, d$) Results on 1.5: u...@host1 ~ $ ls -la //host2/d\$/temp = shows the content of c:\temp on host_2_ (as expected) Results on 1.7: u...@host1 ~ $ ls -l //host2/d\$/temp lrwxrwxrwx (...) //host2/d$/temp - /cygdrive/c/temp = resolves the local junction of host_2_ but translates it to the local junction of host_1_, losing the UNC part (//host2/). Right, that's a problem. Shouldn't this be parsed to //host2/c\$/temp That's not possible since that breaks reparse points via SMB in another way. The drive letters in such a reparse point won't have a meaning at all, unless drive C: is shared as //host/c, drive D: as //host/d, etc. What you're proposing - to use the administrative shares - only works for administrators. ... as with Cygwin 1.5? Actually Cygwin 1.5 didn't parse reparse points at all. It just used them as if they were files or directories. In contrast, the behaviour of Cygwin 1.7, which is to read the actual reparse point content and treat it as symlinks, does not make sense for remote reparse points, apparently. Only the remote system knows how to treat them correctly. So I just applied a patch to Cygwin. In future it will only try to handle reparse points as symlinks if they are on a local filesystem. That should fix the aforementioned problem but keep the current behavior for local reparse points. Thanks for the report, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: 1.7.5-1: problem with settimeofday() gettimeofday()
On May 26 10:22, Christopher Faylor wrote: On Wed, May 26, 2010 at 04:02:45PM +0300, ??? ?? wrote: Hello. It seems that I found a problem with settimeofday() and gettimeofday() calls in a single context. The problem is that if we set a new time with settimeofday() call it completes succefully and system time is updated. But then if we try to get current time with gettimeofday() call it returns old time! I've looked into 'times.cc' and found that 'hires_ms gtod' timer (which is used in gettimeofday()) is not reset with 'hires_ms::prime()' in settimeofday() after system call to Win32 API SetSystemTime() function! I think this is the reason of described behaviour. That sounds right. I'll check in a fix shortly. What happens in other, parallel processes which are calling gettimeofday in a loop? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Reading /proc/registry/... returns extra char
On May 26 17:42, Andrey Repin wrote: Greetings, Corinna Vinschen! $ cat a.dat /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Syst emBootDevice This trailing NUL character was always there, already with Cygwin 1.5. It's part of the file content. If strings are stored with a trailing NUL in a file, you don't want Cygwin to remove it for you, right? Wrong. The training NULL is a string value terminator for REG_SZ variables, also a string separator for REG_MULTI_SZ ones. (Which ends with a spare NULL) It must not be exposed to the user. I disagree. When you're using tools like regtool, you're right. But when accessing the registry as *files* via the virtual /proc filesystem, you want the file content. And the file contains the trailing NUL in REG_SZ and REG_EXPAND_SZ values, and multiple NULs in REG_MULTI_SZ values. What do you suppose Cygwin should do with the NULs in REG_MULTI_SZ values? Just remove them? BTW, get it as a bugreport - reading REG_MULTI_SZ from /proc/registry returns only first string. Yep, that's a bug. I'll look into it. Thanks for the report, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: 1.7.5-1: problem with settimeofday() gettimeofday()
On Wed, May 26, 2010 at 11:56:20AM -0400, Christopher Faylor wrote: On Wed, May 26, 2010 at 04:25:43PM +0200, Corinna Vinschen wrote: On May 26 10:22, Christopher Faylor wrote: On Wed, May 26, 2010 at 04:02:45PM +0300, ??? ?? wrote: Hello. It seems that I found a problem with settimeofday() and gettimeofday() calls in a single context. The problem is that if we set a new time with settimeofday() call it completes succefully and system time is updated. But then if we try to get current time with gettimeofday() call it returns old time! I've looked into 'times.cc' and found that 'hires_ms gtod' timer (which is used in gettimeofday()) is not reset with 'hires_ms::prime()' in settimeofday() after system call to Win32 API SetSystemTime() function! I think this is the reason of described behaviour. That sounds right. I'll check in a fix shortly. What happens in other, parallel processes which are calling gettimeofday in a loop? I think we've always known that long-running cygwin processes did not deal with date/time changes correctly. However, for cygwin processes, in the same session at least, I think that sharing the gtod variable should work. In my limited testing it seems to. The most recent snapshot has this change as well as all of the stuff Corinna has done today: http://cygwin.com/snapshots/ Oh, I forgot to say: Thanks for the test case. Those are always extremely appreciated. 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: 1.7.5-1: problem with settimeofday() gettimeofday()
On Wed, May 26, 2010 at 04:25:43PM +0200, Corinna Vinschen wrote: On May 26 10:22, Christopher Faylor wrote: On Wed, May 26, 2010 at 04:02:45PM +0300, ??? ?? wrote: Hello. It seems that I found a problem with settimeofday() and gettimeofday() calls in a single context. The problem is that if we set a new time with settimeofday() call it completes succefully and system time is updated. But then if we try to get current time with gettimeofday() call it returns old time! I've looked into 'times.cc' and found that 'hires_ms gtod' timer (which is used in gettimeofday()) is not reset with 'hires_ms::prime()' in settimeofday() after system call to Win32 API SetSystemTime() function! I think this is the reason of described behaviour. That sounds right. I'll check in a fix shortly. What happens in other, parallel processes which are calling gettimeofday in a loop? I think we've always known that long-running cygwin processes did not deal with date/time changes correctly. However, for cygwin processes, in the same session at least, I think that sharing the gtod variable should work. In my limited testing it seems to. The most recent snapshot has this change as well as all of the stuff Corinna has done today: http://cygwin.com/snapshots/ 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: Reading /proc/registry/... returns extra char
On May 26 16:34, Corinna Vinschen wrote: On May 26 17:42, Andrey Repin wrote: BTW, get it as a bugreport - reading REG_MULTI_SZ from /proc/registry returns only first string. Yep, that's a bug. I'll look into it. I applied a patch to Cygwin to fix this. Thanks again, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Native 64 bit.
First off, I do not know if we will ever finish this attempt, but we will start and try. We would like to compile cygwin for 64 bit native operation. Our office is switching to all 64 bit systems. Reading: http://cygwin.com/faq/faq.programming.html#faq.programming.building-cygwin Could someone confirm that the gcc, make, perl, and cocom should be be cygwin (32 bit) versions or should they be windows versions? Also should I move this to the cygwin-developers list? The fun will start 7-June-2010, wish us luck. -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: Native 64 bit.
On Wed, May 26, 2010 at 01:13:52PM -0400, Jason Pyeron wrote: First off, I do not know if we will ever finish this attempt, but we will start and try. We would like to compile cygwin for 64 bit native operation. Our office is switching to all 64 bit systems. Reading: http://cygwin.com/faq/faq.programming.html#faq.programming.building-cygwin Could someone confirm that the gcc, make, perl, and cocom should be be cygwin (32 bit) versions or should they be windows versions? Also should I move this to the cygwin-developers list? The fun will start 7-June-2010, wish us luck. Wow, if you're asking questions like this, you have a long road ahead of you. It doesn't matter what you use. Just use whatever works. 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: Native 64 bit.
-Original Message- From: Christopher Faylor Sent: Wednesday, May 26, 2010 13:26 Subject: Re: Native 64 bit. On Wed, May 26, 2010 at 01:13:52PM -0400, Jason Pyeron wrote: First off, I do not know if we will ever finish this attempt, but we will start and try. We would like to compile cygwin for 64 bit native operation. snip/ The fun will start 7-June-2010, wish us luck. Wow, if you're asking questions like this, you have a long road ahead of you. It doesn't matter what you use. Just use whatever works. Got it. We will keep list up to date, and we will send all questions to the dev list when we bump into them. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: Native 64 bit.
On Wed, May 26, 2010 at 1:13 PM, Jason Pyeron jpye...@pdinc.us wrote: First off, I do not know if we will ever finish this attempt, but we will start and try. We would like to compile cygwin for 64 bit native operation. Our office is switching to all 64 bit systems. Reading: http://cygwin.com/faq/faq.programming.html#faq.programming.building-cygwin Could someone confirm that the gcc, make, perl, and cocom should be be cygwin (32 bit) versions or should they be windows versions? Also should I move this to the cygwin-developers list? The fun will start 7-June-2010, wish us luck. You know about http://mingw-w64.sf.net/ right? I sure hope so. If not, please ask me :) What is your end goal? Porting cygwin to win64 is a huge task, and it might not be necessary. We can already cross compile from cygwin32 to native win64 on a win64 system. Is that all you need? If you really are going to port cygwin, you should start by porting all the dependencies. -- 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: Native 64 bit.
-Original Message- From: Eliot Moss Sent: Wednesday, May 26, 2010 14:50 To: Jason Pyeron Subject: Re: Native 64 bit. On 5/26/2010 1:13 PM, Jason Pyeron wrote: First off, I do not know if we will ever finish this attempt, but we will start and try. We would like to compile cygwin for 64 bit native operation. Our office is switching to all 64 bit systems. Jason -- Could you clarify? I run Windows 7 64-bit and cygwin goes fine. Of course cygwin and all the ported Unix programs that run under it live in a 32-bit universe, but that's fine, and I can invoke native 32-bit Windows apps (like Eclipse, say) just fine. What is it you feel you need? Memory access. Linking in other 64 bit dlls. Best wishes -- Eliot Moss -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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
Fw: SVN Core Dump on Cygwin 1.7.1 using UNC Path
BTW Why can't the mail server extract the text/plain portion of an email automatically? - Original Message - From: Chloe Sowers To: cygwin@cygwin.com Sent: Wednesday, May 26, 2010 5:24 PM Subject: Fw: SVN Core Dump on Cygwin 1.7.1 using UNC Path FYI - Original Message - From: Chloe Sowers To: d...@subversion.apache.org Sent: Wednesday, May 26, 2010 5:07 PM Subject: SVC Core Dump http://subversion.tigris.org/issues/show_bug.cgi?id=3647 SVN core dump. CygWin 1.7.1 using UNC path. bash-3.2$ svn commit -m message email.pl assertion svn_path_is_canonical(base, pool) failed: file /usr/src/subversion/ branches/cygwin-1.7/subversion-1.6.6-2/src/subversion-1.6.6/subversion/libsvn_su br/path.c, line 114, function: svn_path_join Aborted (core dumped) bash-3.2$ ls email.pl email2010-05-26.log svn.exe.stackdump synch.pl bash-3.2$ svn --version svn, version 1.6.6 (r40053) compiled Oct 23 2009, 08:41:54 Copyright (C) 2000-2009 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme bash-3.2$ pwd //192.168.168.202/WebPortal/chloe bash-3.2$ uname -a CYGWIN_NT-5.1 dumbopc 1.7.1(0.218/5/3) 2009-12-07 11:48 i686 Cygwin bash-3.2$ svn info Path: . URL: svn+ssh://xxunamex...@svn.xxhostxx.us/home/svn/repos/sfs-serverscripts Repository Root: svn+ssh://xxxuname...@svn.xxxhostxxx.us/home/svn/repos Repository UUID: 972ebe08-67a2-460d-8f53-8e22173697f3 Revision: 3168 Node Kind: directory Schedule: normal Last Changed Author: jxx Last Changed Rev: 3167 Last Changed Date: 2010-05-25 21:14:58 -0400 (Tue, 25 May 2010) bash-3.2$ cat svn.exe.stackdump Stack trace: Frame Function Args 0022C338 7C802542 (0688, EA60, 00A4, 0022C42C) 0022C448 610BADB3 (, 00BB41ED, 0688, ) 0022C528 610B7A37 (, , , ) 0022C578 610B7E4B (0CA0, 0022C5A0, 07E8, 0022C5B8) 0022C638 610B7F71 (0CA0, 0006, 0022C668, 610B8015) 0022C648 610B7FAC (0006, 0022CE88, 55D6, 55D6) 0022C668 610B8015 (6115D054, 6D6B33F0, 6D6B3228, 0072) 0022C698 6100109B (6D6B3228, 0072, 6D6B390D, 6D6B33F0) 0022C6C8 610B5178 (10066EC8, 67DB3424, 10087350, 100669B0) 0022C6F8 67D82ADA (10087350, 0022C720, 0022C728, 67D82CA7) 0022C708 67D82B71 (10066EC8, , , 10087350) 0022C728 67D82CA7 (10066EC8, 67DB6007, 10087350, 6D699C07) 0022C768 67DA39FC (10066EC8, 0022C7C8, 10087350, ) 0022C7D8 67D96A1B (, , , ) 0022C828 67D9785D (0022C868, , 10066C60, ) 0022C888 67DA9E7E (1007CC00, 100669B0, 1007CC00, 100669B0) End of stack trace (more stack frames may be present) -- 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: Native 64 bit.
On 5/26/2010 4:40 PM, Jason Pyeron wrote: Memory access. Linking in other 64 bit dlls. Ok ... so why is 64-bit mingw not suitable? -- Eliot -- 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: Fw: SVN Core Dump on Cygwin 1.7.1 using UNC Path
On Wed, May 26, 2010 at 05:32:15PM -0400, Chloe Sowers wrote: BTW Why can't the mail server extract the text/plain portion of an email automatically? Because it doesn't want to. Why can't you do a little research before sending email to a mailing list? Same reason, I suspect. 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: Encounter undefined reference to `_libintl_dgettext'
Hi Yaakov, How do i apply the patches you mentioned in the url? I am quite new to cygwin. I am using libgphoto2-2.4.9.1. Thanks! Yaakov (Cygwin/X) wrote: On 2010-05-25 06:15, aldray wrote: Hi all, I encounter some issue when installing gphoto on cygwin. Anyone knows how to resolve this? http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/graphics/libgphoto2/ 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 -- View this message in context: http://old.nabble.com/Encounter-undefined-reference-to-%60_libintl_dgettext%27-tp28667111p28688764.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: Encounter undefined reference to `_libintl_dgettext'
On 5/26/2010 10:25 PM, aldray wrote: Hi Yaakov, How do i apply the patches you mentioned in the url? I am quite new to cygwin. The README explains that. I am using libgphoto2-2.4.9.1. If you really need 2.4.9.1, you'll have to build this yourself, as you intended. But if you're flexible, you'll find a version of this at http://sourceware.org/cygwinports/ that you can just install with 'setup.exe', which is easier. ;-) -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ 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
lapack: packaging error
liblapack-devel ships blas.pc and lapack.pc in /usr/lib. These must be in /usr/lib/pkgconfig for pkg-config to find them. 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: Native 64 bit.
-Original Message- From: Eliot Moss Sent: Wednesday, May 26, 2010 18:13 Subject: Re: Native 64 bit. On 5/26/2010 4:40 PM, Jason Pyeron wrote: Memory access. Linking in other 64 bit dlls. Ok ... so why is 64-bit mingw not suitable? Common / consistent process. They other systems we use, use a cygwin stack. -- Eliot -- 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 -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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
Error While compiling
Hi, While i was trying to compile a file, i was getting the error: $ make defaultCompiler -c eispack.F make: defaultCompiler: Command not found make: *** [eispack.o] Error 127 Cab you help to figure it out. Thanks in advance for your help Regards, Akash -- 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: Error While compiling
On Wed, May 26, 2010 at 10:00:36PM -0600, aka...@nmsu.edu wrote: Hi, While i was trying to compile a file, i was getting the error: $ make defaultCompiler -c eispack.F make: defaultCompiler: Command not found make: *** [eispack.o] Error 127 Cab you help to figure it out. Thanks in advance for your help Whatever this is, it's not a Cygwin problem. You need to look at the makefile for the program that you're building and figure out what's wrong. -- 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: brltty 4.2-1
Version 4.2-1 of brltty has been uploaded. It is a background process (daemon) providing access to the Windows Console for a blind person using a refreshable braille display. -- brltty-4.2-1 -- 2010-05-12 --- New upstream version. If you have questions or comments, please send them to the Cygwin mailing list at: cyg...@cygwin.com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
