Re: [RFU] plotutils-2.6-2 (was [ITA] plotutils)
On 24/01/2010 01:18, Marco Atzeri wrote: wget -r -np -nH --cut-dirs=2 http://matzeri.altervista.org/cygwin-1.7/plotutils Uploaded; thanks for adopting. Yaakov
RFU: mercurial-1.4.2-1
New upstream release: wget \ http://cante.net/~jaalto/tmp/cygwin/mercurial/mercurial-1.4.2-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/mercurial/mercurial-1.4.2-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/mercurial/setup.hint Jari
Re: RFU: mercurial-1.4.2-1
On Jan 24 14:23, Jari Aalto wrote: New upstream release: wget \ http://cante.net/~jaalto/tmp/cygwin/mercurial/mercurial-1.4.2-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/mercurial/mercurial-1.4.2-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/mercurial/setup.hint Uploaded. There are still old releases 1.1-1, 1.3.1-1, 1.3.1-15. Can they go? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] cppcheck-1.40-1
Done. Which of 1.34-1, 1.35-1, or 1.39-1 should be kept as previous? Please keep 1.39-1 as previous and you can remove the rest if need be. Chris -- Chris Sutcliffe http://emergedesktop.org
Some troubles with packaging toolchains (was Re: Need input on packaging mingw-w64 for Cygwin)
Hi, While packaging new binutils for cross mingw and mingw-w64, I've noticed there were some duplicate files, but I'm not sure how to handle them with cygport, advice welcome. The duplicate files are mostly under usr/share/locale/ and libiberty.a. We could fix this by making all cross toolchains use seperate --prefix and --with-sysroot, but I don't know if its appropriate. There are also some issues for DLL'ized GCC target libs, such as libstdc++-6.dll. I've decided they should be disabled for mingw and mingw-w64 based 4.x toolchains for the moment, as they all wanted to be installed as libstdc++-6.dll into bindir, causing potential confusion for users. It can be re-enabled after its fixed in upstream GCC and libtool.
Re: Some troubles with packaging toolchains (was Re: Need input on packaging mingw-w64 for Cygwin)
On 24/01/2010 19:03, JonY wrote: While packaging new binutils for cross mingw and mingw-w64, I've noticed there were some duplicate files, but I'm not sure how to handle them with cygport, advice welcome. It's hard to give advice without seeing what you have already. How about showing us your .cygport files? The duplicate files are mostly under usr/share/locale/ Unless you can $triplet-namespace the textdomain, you might just need to not package those. and libiberty.a. Wouldn't this belong in /usr/$triplet/lib/? We could fix this by making all cross toolchains use seperate --prefix and --with-sysroot, but I don't know if its appropriate. That shouldn't be necessary. There are also some issues for DLL'ized GCC target libs, such as libstdc++-6.dll. I've decided they should be disabled for mingw and mingw-w64 based 4.x toolchains for the moment, as they all wanted to be installed as libstdc++-6.dll into bindir, causing potential confusion for users. It can be re-enabled after its fixed in upstream GCC and libtool. Whatever you do, the cross-compilers need to match what the target's native compiler would do. So if mingw's own toolchains are shipping and using shared GCC libraries, AFAICS you should do the same by enabling shared libraries and shipping the *import* libs but NOT the DLLs (which you only need to *execute* programs, which you're not doing because this is a *cross*-compile situation). Yaakov
Re: Some troubles with packaging toolchains (was Re: Need input on packaging mingw-w64 for Cygwin)
Yaakov (Cygwin/X) wrote: On 24/01/2010 19:03, JonY wrote: There are also some issues for DLL'ized GCC target libs, such as libstdc++-6.dll. I've decided they should be disabled for mingw and mingw-w64 based 4.x toolchains for the moment, as they all wanted to be installed as libstdc++-6.dll into bindir, causing potential confusion for users. It can be re-enabled after its fixed in upstream GCC and libtool. Whatever you do, the cross-compilers need to match what the target's native compiler would do. So if mingw's own toolchains are shipping and using shared GCC libraries, AFAICS you should do the same by enabling shared libraries and shipping the *import* libs but NOT the DLLs (which you only need to *execute* programs, which you're not doing because this is a *cross*-compile situation). There's no conflict between the cygwin libraries and the mingw ones; the gcc devs took care that the cygwin DLLs used the 'cyg*dll' pattern. Now, the conflict between the 32bit and 64bit DLLs? IMO, that would have been a show-stopper before rolling out the 64bit compiler in the first place: First, Do No Harm. Surely is was self-evidently obvious that people would want to run/install both 64bit and 32bit apps on the same system? But no care was taken to prevent this conflict. Sigh. However, given that a /real/ solution to this problem is not likely to come soon, I'd probably just install the runtime DLLs into the /usr/$triple/bin area -- since the $triples are different -- and let the end-user copy whichever one she wants into /usr/bin manually. -- Chuck
Re: Some troubles with packaging toolchains (was Re: Need input on packaging mingw-w64 for Cygwin)
On 1/25/2010 09:34, Yaakov (Cygwin/X) wrote:
On 24/01/2010 19:03, JonY wrote:
While packaging new binutils for cross mingw and mingw-w64, I've
noticed there were some duplicate files, but I'm not sure how to handle
them with cygport, advice welcome.
It's hard to give advice without seeing what you have already. How about
showing us your .cygport files?
Oh right. Draft 32bit and 64bit targeting binutils cygport attached.
The duplicate files are mostly under usr/share/locale/
Unless you can $triplet-namespace the textdomain, you might just need to
not package those.
and libiberty.a.
Wouldn't this belong in /usr/$triplet/lib/?
no, it is built by cygwin gcc for use with cross binutils, so its
considered native.
We could fix this by making all cross toolchains use seperate --prefix
and --with-sysroot, but I don't know if its appropriate.
That shouldn't be necessary.
There are also some issues for DLL'ized GCC target libs, such as
libstdc++-6.dll. I've decided they should be disabled for mingw and
mingw-w64 based 4.x toolchains for the moment, as they all wanted to be
installed as libstdc++-6.dll into bindir, causing potential confusion
for users. It can be re-enabled after its fixed in upstream GCC and
libtool.
Whatever you do, the cross-compilers need to match what the target's
native compiler would do. So if mingw's own toolchains are shipping and
using shared GCC libraries, AFAICS you should do the same by enabling
shared libraries and shipping the *import* libs but NOT the DLLs (which
you only need to *execute* programs, which you're not doing because this
is a *cross*-compile situation).
The import libs do not conflict, just the runtime dlls. When executing
the applications, we may have up to 3 libstdc++-6.dll, incompatible to
each other.
This could be changed in the upstream GCC with libw32stdc++-6 as 32bit
mingw-w64 toolchain, libw64stdc++-6 as 64bit mingw-w64, and the normal
libstdc++-6 for the mingw.org toolchain. Now all 3 can live side by
side.
DESCRIPTION=Binutils for Win x86 targets.
HOMEPAGE=http://www.gnu.org/software/binutils/;
SRC_URI=http://ftp.gnu.org/gnu/binutils/binutils-${PV}.tar.bz2;
PKG_NAMES=${PN} ${PN}-doc
PKG_CONTENTS[0]=usr/bin/ usr/i686-w64-mingw32/ usr/share/locale/
PKG_CONTENTS[1]=usr/share/doc/ usr/share/info/ usr/share/man/
SRC_DIR=binutils-${PV}
PKG_HINTS=setup doc
src_compile(){
cd ${B}
cygconf --build=i686-pc-cygwin --host=i686-pc-cygwin
--target=i686-w64-mingw32
cygmake
}
DESCRIPTION=Binutils for Win x64 targets.
HOMEPAGE=http://www.gnu.org/software/binutils/;
SRC_URI=http://ftp.gnu.org/gnu/binutils/binutils-${PV}.tar.bz2;
PKG_NAMES=${PN} ${PN}-doc
PKG_CONTENTS[0]=usr/bin/ usr/x86_64-w64-mingw32/ usr/share/locale/
PKG_CONTENTS[1]=usr/share/doc/ usr/share/info/ usr/share/man/
SRC_DIR=binutils-${PV}
PKG_HINTS=setup doc
src_compile(){
cd ${B}
cygconf --build=i686-pc-cygwin --host=i686-pc-cygwin
--target=x86_64-w64-mingw32
cygmake
}
Tempo minimo - Salario massimo!
International Credit Online Rappresentante finanziario Informazioni di posti di lavoro Post Date: 24/01/2010 Salario: 2.000 EUR/mese + 5% di ciascuna operazione di pagamento Location: Italia Generale Description Accettazione dei pagamenti dai clienti nella vostra zona e favorire a realizzare gli obiettivi finanziarie di Compagnia. Le condizioni di lavoro Il lavoro tranne internet - ufficio, e anche con le banche e i sistemi di trasferimenti veloci. Contact Details / Apply for this Job Se a Voi interessa questo lavoro, mandate il curriculum alla nostra [ internationalcreditonl...@gmail.com ] In attesa di Vostro riscontro, distinti saluti manager HR Josef Paterson -- 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-01-24 14:43:53 Modified files: winsup/cygwin : ChangeLog nlsfuncs.cc Log message: * nlsfuncs.cc (__set_charset_from_locale): Fix comment. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4780r2=1.4781 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/nlsfuncs.cc.diff?cvsroot=srcr1=1.3r2=1.4
[ANNOUNCEMENT] Updated: {octave,octave-devel,octave-doc}-3.2.4-1
New versions 3.2.4-1 of octave, octave-devel, octave-doc are available in the Cygwin distribution: This is a bugfix release versus previous 3.2.x For all the main changes http://www.gnu.org/software/octave/NEWS-3.2.html DESCRIPTION The GNU Octave language for numerical computations Octave is a (mostly Matlab (R) compatible) high-level language, primarily intended for numerical computations. It provides a convenient command-line interface for solving linear and nonlinear problems numerically. HOMEPAGE http://www.gnu.org/software/octave/ Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) 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
[ANNOUNCEMENT] Updated: qrupdate-1.1.0-1
The version 1.1.0-1 of qrupdate(source), libqrupdate-devel, libqrupdate0 have been uploaded. It is one of the package needed to fully compile Octave-3.2.x and following DESCRIPTION QRUPDATE is a library for fast updating of QR and Cholenski decompositions. HOMEPAGE http://qrupdate.sourceforge.net/ CHANGES This is a extension upstream relase. It now includes LU updating routines Regards Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin at 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.com at 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: Please support CP932. (I have problem using subversion with SJIS)
On Jan 23 22:31, Andy Koppe wrote: Corinna Vinschen: I applied a patch which handles the characters 0x5c and 0cfe differently if the charset is set to SJIS Something's going seriously wrong with this, and I'd suspect it's to do with turning backslashes into yen symbols. Right. It occured to me tonight that this will not work from a filesystem point-of-view. The people who decided to overload backslash and tilde in the ASCII range with different symbols in SJIS still need some serious knock on their heads. No wonder the Microsoft guys kept the binary values of characters intact, especially due to the backslash problem. Not sure what could be done about it. Remove SJIS support in favour of CP932? In theory, we could be able to keep SJIS support in. The Cygwin-internal function converting multibyte strings to Unicode filenames would have to use CP932. Only on the application level the conversion would use SJIS. There's no system API which takes wchar_t strings, so all strings are exchanged between application and system using multibyte strings. Since the multibytes strings are the same, that should give a round-trip which still works for Win32 filenames: Input string: \x5e\xfe Application: mbstowcs (\x5e\xfe) == L\x00a5\x203e wcstombs (L\x00a5\x203e) == x5e\xfe Cygwin sys_mbstowcs (\x5e\xfe) == L\x005e\x007e sys_wcstombs (L\x005e\x007e) == x5e\xfe 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: Please support CP932. (I have problem using subversion with SJIS)
On Jan 24 10:37, Corinna Vinschen wrote: On Jan 23 22:31, Andy Koppe wrote: Corinna Vinschen: I applied a patch which handles the characters 0x5c and 0cfe differently if the charset is set to SJIS Something's going seriously wrong with this, and I'd suspect it's to do with turning backslashes into yen symbols. Right. It occured to me tonight that this will not work from a filesystem point-of-view. The people who decided to overload backslash and tilde in the ASCII range with different symbols in SJIS still need some serious knock on their heads. No wonder the Microsoft guys kept the binary values of characters intact, especially due to the backslash problem. Not sure what could be done about it. Remove SJIS support in favour of CP932? In theory, we could be able to keep SJIS support in. The Cygwin-internal function converting multibyte strings to Unicode filenames would have to use CP932. Only on the application level the conversion would use SJIS. There's no system API which takes wchar_t strings, so all strings are exchanged between application and system using multibyte strings. Since the multibytes strings are the same, that should give a round-trip which still works for Win32 filenames: Input string: \x5e\xfe Application: mbstowcs (\x5e\xfe) == L\x00a5\x203e wcstombs (L\x00a5\x203e) == x5e\xfe Cygwin sys_mbstowcs (\x5e\xfe) == L\x005e\x007e sys_wcstombs (L\x005e\x007e) == x5e\xfe ...and, if we implement it that way, do we really still need support for a CP932 charset? -- 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: Please support CP932. (I have problem using subversion with SJIS)
2010/1/24 Corinna Vinschen: Something's going seriously wrong with this, and I'd suspect it's to do with turning backslashes into yen symbols. Right. It occured to me tonight that this will not work from a filesystem point-of-view. The people who decided to overload backslash and tilde in the ASCII range with different symbols in SJIS still need some serious knock on their heads. No wonder the Microsoft guys kept the binary values of characters intact, especially due to the backslash problem. I looked into this a bit more, out of morbid curiosity. Actually it's Microsoft themselves (or IBM?) who have to take a large part of the blame here, for deciding to use the backslash as the DOS directory separator. ISO-646, which is an internationalized version of ASCII, defines the backslash codepoint as 'localizable', and many national variants of it do define it as something else. (See http://en.wikipedia.org/wiki/ISO/IEC_646) To work around this issue in the case of SJIS, MS decided to stick with the backslash for CP932, and instead implemented a nasty hack to achieve some sort of SJIS compatibility: Japanese Windows fonts, including Unicode fonts, have a Yen symbol at the backspace position. In theory, we could be able to keep SJIS support in. The Cygwin-internal function converting multibyte strings to Unicode filenames would have to use CP932. Only on the application level the conversion would use SJIS. I've pondered that, and I don't think that's worthwhile. It's still going to cause trouble, e.g. with the backslash's use as an escape character and the tilde's use in shell expansions. Also, there are some more differences between standard SJIS and CP932 (although none as serious as the backslash and tilde issues), so more work would be needed to get that right. Finally, CP932 is the only SJIS that people are realistically going to care about, since that's what's in widespread use due to Windows. If someone really needs standard SJIS for converting documents or something, they can use iconv. Therefore I've changed my mind on whether to keep SJIS and CP932 separate: I think we should stick with the locale.SJIS charset as it is in 1.7.1, except that nl_langinfo(CODESET) for it should return CP932 instead of SJIS, to make sure iconv uses the right charset, thereby addressing the OP's issue. Andy -- 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: Please support CP932. (I have problem using subversion with SJIS)
On Jan 24 10:17, Andy Koppe wrote: 2010/1/24 Corinna Vinschen: The people who decided to overload backslash and tilde in the ASCII range with different symbols in SJIS still need some serious knock on their heads. No wonder the Microsoft guys kept the binary values of characters intact, especially due to the backslash problem. I looked into this a bit more, out of morbid curiosity. [...] Interesting. In theory, we could be able to keep SJIS support in.C [...] The I've pondered that, and I don't think that's worthwhile. It's still going to cause trouble, e.g. with the backslash's use as an escape character and the tilde's use in shell expansions. Also, there are some more differences between standard SJIS and CP932 (although none as serious as the backslash and tilde issues), so more work would be needed to get that right. Finally, CP932 is the only SJIS that people are realistically going to care about, since that's what's in widespread use due to Windows. If someone really needs standard SJIS for converting documents or something, they can use iconv. Therefore I've changed my mind on whether to keep SJIS and CP932 separate: I think we should stick with the locale.SJIS charset as it is in 1.7.1, except that nl_langinfo(CODESET) for it should return CP932 instead of SJIS, to make sure iconv uses the right charset, thereby addressing the OP's issue. You have a point there. And it's the most easy way to implement it, which is a good argument in itself. 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: question on gdb
On 24/01/2010 07:42, Marco Atzeri wrote: My question however is about the gdb backtrace, is the Cannot access memory at address 0x1a at # 9 normal ? I wouldn't read too much into it. Could indicate that there's some kind of corruption at the top end of the stack, or it could just be gdb getting confused about a value that was in a register at the start of execution but has long since been lost. Program received signal SIGSEGV, Segmentation fault. 0x20f414d0 in ?? () (gdb) backtrace #0 0x20f414d0 in ?? () #1 0x6112e117 in __call_exitprocs () from /usr/bin/cygwin1.dll #2 0x6110b6da in exit () from /usr/bin/cygwin1.dll #3 0x61004e5a in cygwin_exit () from /usr/bin/cygwin1.dll #4 0x610b6838 in _sigfe () from /usr/bin/cygwin1.dll #5 0x0022bba8 in ?? () #6 0x6c4e401e in cygstdc++-6!_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc () from /usr/bin/cygstdc++-6.dll #7 0x6e5c8c65 in _fu4930___ZSt4cerr () at ../../octave_clone/src/toplev.cc:625 #8 0x6e58fd9c in _fu4441___ZN8file_ops14static_members8instanceE () at ../../octave_clone/src/octave.cc:876 #9 0x00401167 in main (argc=Cannot access memory at address 0x1a ) at ../../octave_clone/src/main.c:35 Looks like maybe an exception was thrown in ostream::operator(const char*). Looks also like somewhere up the stack is file_ops::static_members::instance(), and it's quite possibly trying to print something to std::cerr. Possibly a NULL pointer? Also, you want to set breakpoints on __call_exitprocs and on atexit, and see what functions are getting registered, whether there's a corrupt entry pointing at 0x20f414d0 or whether one of the exitprocs is going astray and jumping into space. 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
Re: Please support CP932. (I have problem using subversion with SJIS)
On Jan 24 13:05, Corinna Vinschen wrote: On Jan 24 10:17, Andy Koppe wrote: Therefore I've changed my mind on whether to keep SJIS and CP932 separate: I think we should stick with the locale.SJIS charset as it is in 1.7.1, except that nl_langinfo(CODESET) for it should return CP932 instead of SJIS, to make sure iconv uses the right charset, thereby addressing the OP's issue. You have a point there. And it's the most easy way to implement it, which is a good argument in itself. I checked that in now. I also kept charset CP932 in. After all, it doesn't hurt to support that as well. Nayuta, can you please test if the latest from CVS works for you even with LANG=ja_JP.SJIS? 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
[ANNOUNCEMENT] Updated: cppcheck-1.40-1
Version 1.40-1 of cppcheck has been uploaded, following the upstream release. cppcheck is a tool for static C/C++ code analysis. It tries to detect bugs that your C/C++ compiler don't see. The goal is no false positives. cppcheck is versatile. You can check non-standard code that includes various compiler extensions, inline assembly code, etc. *** 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. -- Chris Sutcliffe http://emergedesktop.org -- 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
FLTK versions in Cygwin [was: Re: units: update, FHS compliance]
Yaakov (Cygwin/X) wrote: On 23/01/2010 09:32, Albrecht Schlosser wrote: Well, then there are probably good news from FLTK. The current development version (1.3.0) can be configured to work with cygwin/X11 OOTB: $ ./configure --enable-cygwin --enable-x11 I haven't tried the 1.3 branch, but the 2.0 branch certainly does NOT work with Cygwin/X11 OOTB: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/x11/fltk2/r6403-configure-cygwin.patch Defining _WIN32, using -mwindows, and not supporting shared libraries is *not* what I call working with Cygwin. Yes, FLTK 2 is an experimental version that stalled, there's currently no development, and it will probably be dropped completely. There are plans, however, to combine the FLTK 2 API with the FLTK 1.3 base to build a new FLTK 3 version, but that's only a *plan*. I also looked at your patch and the cygport file at: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/x11/fltk2/fltk2-2.0.x.6879-1.cygport There I saw a reference to dillo2: this unfortunately uses FLTK2, and if you want to support this, the cygport version would have to stay with FLTK 2. But please note that FLTK 2 has a different API than FLTK 1.1 and FLTK 1.3. For the latest stable release (1.1.10) a configure patch to make it work with X11 has been posted by the Cygwin maintainer (Teun Burgers), but didn't make it into the final release. He also supplied the configure/X11 patch for the current development version. One way or another, we do need to hear from Teun so that we can sort out the FLTK package. Agreed. The current Cygwin version is 1.1.8, the latest stable release is 1.1.10. Current development is 1.3.0, but as I wrote, a release is not yet available. For the different versions of FLTK please see this interesting article: http://www.fltk.org/articles.php?L825 Albrecht -- 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: FLTK versions in Cygwin [was: Re: units: update, FHS compliance]
Albrecht Schlosser wrote: Yaakov (Cygwin/X) wrote: [...] I haven't tried the 1.3 branch, but the 2.0 branch certainly does NOT work with Cygwin/X11 OOTB: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/x11/fltk2/r6403-configure-cygwin.patch Defining _WIN32, using -mwindows, and not supporting shared libraries is *not* what I call working with Cygwin. Addition: FLTK 1.3.0, just tested: $ ./configure --enable-cygwin --enable-x11 --enable-shared $ make creates working Cygwin/X11 .exe files and additional: src/cygfltk-1.3.dll src/cygfltk_forms-1.3.dll src/cygfltk_images-1.3.dll src/libfltk.dll.a src/libfltk_forms.dll.a src/libfltk_images.dll.a unfortunately these are in the src/ directory, but that's a minor issue. Maybe they are not installed correctly, but that can be fixed. Albrecht -- 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: Please support CP932. (I have problem using subversion with SJIS)
2010/1/24 Corinna Vinschen corinna-cyg...@cygwin.com: On Jan 24 13:05, Corinna Vinschen wrote: On Jan 24 10:17, Andy Koppe wrote: Therefore I've changed my mind on whether to keep SJIS and CP932 separate: I think we should stick with the locale.SJIS charset as it is in 1.7.1, except that nl_langinfo(CODESET) for it should return CP932 instead of SJIS, to make sure iconv uses the right charset, thereby addressing the OP's issue. You have a point there. And it's the most easy way to implement it, which is a good argument in itself. I checked that in now. I also kept charset CP932 in. After all, it doesn't hurt to support that as well. Nayuta, can you please test if the latest from CVS works for you even with LANG=ja_JP.SJIS? Thank you for implementing CP932 and changing SJIS to an alias of CP932. I'll test it tomorrow. 2010/1/24 Andy Koppe andy.ko...@gmail.com: I think that's the correct thing to do, but it'll likely break other stuff. Seems SJIS really isn't suited for Unix command line use. All the more reason to make EUC-JP the default for ja_JP I guess. I prefer UTF-8 (or CP932) for the default for ja_JP, but I don't know that this is a consensus of Japanese. -- nayuta -- 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: Please support CP932. (I have problem using subversion with SJIS)
On Jan 25 01:00, Nayuta Taga wrote: 2010/1/24 Corinna Vinschen corinna-cyg...@cygwin.com: Nayuta, can you please test if the latest from CVS works for you even with LANG=ja_JP.SJIS? Thank you for implementing CP932 and changing SJIS to an alias of CP932. I'll test it tomorrow. Thanks. I prefer UTF-8 (or CP932) for the default for ja_JP, but I don't know that this is a consensus of Japanese. The Unix consensus is apparently EUC-JP and that's what Cygwin 1.7.2 will use as default as well. If you want UTF-8, just use ja_JP.UTF-8. 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: question on gdb
On Sun, Jan 24, 2010 at 07:42:32AM +, Marco Atzeri wrote: Hi, recently, after some change in the source, the octave development branch started to SIGSEV on exit. The strange issue is that this happen only for cygwin and not on the other platforms. I have not yet found a solution, only a possible workaround removing some specific C++ free actions, so to fallback to libstdc++ cleaning activity. My question however is about the gdb backtrace, is the Cannot access memory at address 0x1a at # 9 normal ? Unfortunately I am not really an expert on gdb: It happens sometimes but it does seem like something is screwed up somewhere sinc eyou have _sigfe in the stack trace with functions from other DLLs below it. That doesn't seem right. It looks like the stack is damaged. Can you set a breakpoint at cygwin_exit and (eventually) step into atexit to see where the problem is occurring? It sounds like a destructor is having problems. cgf Here the gdb session -- octave:1 exit Program received signal SIGSEGV, Segmentation fault. 0x20f414d0 in ?? () (gdb) backtrace #0 0x20f414d0 in ?? () #1 0x6112e117 in __call_exitprocs () from /usr/bin/cygwin1.dll #2 0x6110b6da in exit () from /usr/bin/cygwin1.dll #3 0x61004e5a in cygwin_exit () from /usr/bin/cygwin1.dll #4 0x610b6838 in _sigfe () from /usr/bin/cygwin1.dll #5 0x0022bba8 in ?? () #6 0x6c4e401e in cygstdc++-6!_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc () from /usr/bin/cygstdc++-6.dll #7 0x6e5c8c65 in _fu4930___ZSt4cerr () at ../../octave_clone/src/toplev.cc:625 #8 0x6e58fd9c in _fu4441___ZN8file_ops14static_members8instanceE () at ../../octave_clone/src/octave.cc:876 #9 0x00401167 in main (argc=Cannot access memory at address 0x1a ) at ../../octave_clone/src/main.c:35 (gdb) --- -- 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: FLTK versions in Cygwin [was: Re: units: update, FHS compliance]
On 24/01/2010 09:00, Albrecht Schlosser wrote: $ ./configure --enable-cygwin --enable-x11 --enable-shared Indeed, this does appear to work OOTB, although --enable-cygwin and --enable-x11 should be the defaults. I shouldn't have to say that I do *not* want to cross-compile (besides that -mno-cygwin is no longer supported). unfortunately these are in the src/ directory, but that's a minor issue. Maybe they are not installed correctly, but that can be fixed. They are not installed at all by 'make install'. Yes, FLTK 2 is an experimental version that stalled, there's currently no development, and it will probably be dropped completely. I had been wondering why it's been so many weeks since the last weekly snapshot. Agreed. The current Cygwin version is 1.1.8, the latest stable release is 1.1.10. Current development is 1.3.0, but as I wrote, a release is not yet available. I have added a .cygport for the latest 1.3 snapshot: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/x11/fltk/ 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
Fyi Apache2 notes: No space left on device / Cannot create SSLMutex
I restarted apache many times today, just a few minutes ago, it would not start. I am running apache from the command line, and not the cygrunsrv. I do not have time to investigate why this happened, but I might happen to someone else, so here is what I have: jpye...@phoenix /srv/www/cgi-bin $ tail -f /var/log/apache2/error_log jpye...@phoenix /srv/www/cgi-bin $ [Sun Jan 24 14:28:24 2010] [warn] Init: Session Cache is not configured [hint: SSLSessionCache] [Sun Jan 24 14:28:25 2010] [notice] Digest: generating secret for digest authentication ... [Sun Jan 24 14:28:25 2010] [notice] Digest: done [Sun Jan 24 14:28:25 2010] [warn] pid file /var/run/httpd2.pid overwritten -- Unclean shutdown of previous Apache run? [Sun Jan 24 14:28:25 2010] [emerg] (28)No space left on device: Couldn't create accept lock (/var/run/accept.lock.1768) (5) jpye...@phoenix /srv/www/cgi-bin $ df -h FilesystemSize Used Avail Use% Mounted on C:/cygwin/bin 112G 104G 8.6G 93% /usr/bin C:/cygwin/lib 112G 104G 8.6G 93% /usr/lib C:/cygwin 112G 104G 8.6G 93% / C:112G 104G 8.6G 93% /cygdrive/c Z:228G 217G 11G 96% /cygdrive/z jpye...@phoenix /srv/www/cgi-bin $ rm /var/run/httpd2.pid jpye...@phoenix /srv/www/cgi-bin $ /usr/sbin/httpd2.exe [Sun Jan 24 14:28:58 2010] [warn] Init: Session Cache is not configured [hint: SSLSessionCache] [Sun Jan 24 14:28:58 2010] [crit] (28)No space left on device: mod_rewrite: could not create rewrite_log_lock Configuration Failed Segmentation fault (core dumped) jpye...@phoenix /srv/www/cgi-bin $ /usr/sbin/httpd2.exe jpye...@phoenix /srv/www/cgi-bin $ [Sun Jan 24 14:29:53 2010] [error] (28)No space left on device: Cannot create SSLMutex Configuration Failed [Restart cygserver, gut feeling] jpye...@phoenix /srv/www/cgi-bin $ /usr/sbin/httpd2.exe jpye...@phoenix /srv/www/cgi-bin $ [Sun Jan 24 14:30:25 2010] [warn] Init: Session Cache is not configured [hint: SSLSessionCache] [Sun Jan 24 14:30:26 2010] [notice] Digest: generating secret for digest authentication ... [Sun Jan 24 14:30:26 2010] [notice] Digest: done [Sun Jan 24 14:30:26 2010] [notice] Apache/2.2.6 (Unix) mod_ssl/2.2.6 OpenSSL/0.9.8k DAV/2 configured -- resuming normal operations jpye...@phoenix /srv/www/cgi-bin $ uname -a CYGWIN_NT-5.1 phoenix 1.7.0(0.212/5/3) 2009-08-20 10:56 i686 Cygwin jpye...@phoenix /srv/www/cgi-bin $ cygcheck -c Cygwin Package Information Package Version Status snip/ apache 1.3.33-2Incomplete apache2 2.2.6-1 OK apache2-devel 2.2.6-1 OK apache2-manual 2.2.6-1 OK snip/ cygport 0.9.9-1 OK cygrunsrv 1.34-1 OK cygutils1.4.0-1 OK cygwin 1.7.0-60OK cygwin-doc 1.5-1 OK cygwin-x-doc1.1.0-1 OK snip/ -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - 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: Fyi Apache2 notes: No space left on device / Cannot create SSLMutex
On Sun, Jan 24, 2010 at 02:40:32PM -0500, Jason Pyeron wrote: I restarted apache many times today, just a few minutes ago, it would not start. I am running apache from the command line, and not the cygrunsrv. I do not have time to investigate why this happened, but I might happen to someone else, so here is what I have: jpye...@phoenix /srv/www/cgi-bin $ tail -f /var/log/apache2/error_log This is probably a complete out-of-left-field question but this isn't what is causing the problems with thetvdb.com is it? It's a funny coincidence that this bug report would come in today while thetvdb.com was having similar problems with apache. 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: Problem with svn and users over multiple machines
On 01/23/2010 03:42 AM, Gary . wrote: Clearly, they're different, which is what I mean when I say I shouldn't have, I should have done something else instead. How can I add the user and group to sunflower (the second machine) and ensure they are identical to those on mimosa, at least as far as the areas Cygwin is concerned about, given that they are first added using the Windows util? If you're on a domain, you wanted a domain user. Then you could ask mkpasswd and mkgroup to add the domain user, which would have the domain user SID. Alternatively, I think you can get away with copying the entries in '/etc/passwd' and '/etc/group' to sunflower. You'll have to be aware of this if you update these files in the future with 'mkpasswd'/'mkgroup'. I haven't tried doing this so it's possible that this won't work, in which case you're back to the domain option. -- 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
RE: Fyi Apache2 notes: No space left on device / Cannot create SSLMutex
-Original Message- From: Christopher Faylor Sent: Sunday, January 24, 2010 15:13 Subject: Re: Fyi Apache2 notes: No space left on device / Cannot create SSLMutex On Sun, Jan 24, 2010 at 02:40:32PM -0500, Jason Pyeron wrote: I restarted apache many times today, just a few minutes ago, it would not start. I am running apache from the command line, and not the cygrunsrv. I do not have time to investigate why this happened, but I might happen to someone else, so here is what I have: jpye...@phoenix /srv/www/cgi-bin $ tail -f /var/log/apache2/error_log This is probably a complete out-of-left-field question but this isn't what is causing the problems with thetvdb.com is it? It's a funny coincidence that this bug report would come in today while thetvdb.com was having similar problems with apache. I did not know anyone else was having any issues. Feel free to have whoever contact me on or off list as appropriate. Going back to my 20 hour Sunday workday now -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - 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: FLTK versions in Cygwin [was: Re: units: update, FHS compliance]
Yaakov (Cygwin/X) wrote: On 24/01/2010 09:00, Albrecht Schlosser wrote: $ ./configure --enable-cygwin --enable-x11 --enable-shared Indeed, this does appear to work OOTB, although --enable-cygwin and --enable-x11 should be the defaults. I shouldn't have to say that I do *not* want to cross-compile (besides that -mno-cygwin is no longer supported). Well, the defaults are not selected for Cygwin builds, and they are okay for normal Windows GDI builds. But you are right for Cygwin. I'am aware that -mno-cygwin is no longer supported, but there's nothing we can do until a working gcc-4 cross compiler exists. So long we need to use gcc-3 for Windows/GDI builds (or Cygwin). unfortunately these are in the src/ directory, but that's a minor issue. Maybe they are not installed correctly, but that can be fixed. They are not installed at all by 'make install'. Yep, that's what I expected, but didn't check (yet). This may well be changed... Yes, FLTK 2 is an experimental version that stalled, there's currently no development, and it will probably be dropped completely. I had been wondering why it's been so many weeks since the last weekly snapshot. Agreed. The current Cygwin version is 1.1.8, the latest stable release is 1.1.10. Current development is 1.3.0, but as I wrote, a release is not yet available. I have added a .cygport for the latest 1.3 snapshot: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/x11/fltk/ Wow, that was fast. I don't know cygport, but I can see one small glitch: Fluid is called fluid[.exe] and not fluid2, as in FLTK 2, and the man page is fluid[.man] and not fluid2. Albrecht -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Cygwin Not Reading inittab?
I'm trying to respawn an agetty in inittab so I can use Cygwin from a serial terminal. Nothing happens. When I execute the agetty manually I do get a login prompt at the remote terminal so I know my serial port and connection are good. Is there a trick to get cygwin to read and execute lines from inittab? I'm running Cygwin 1.71 on Win XP Pro with SP3 if that matters. I'm a total noob with Linux/Cygwin so please make your explanation simple (step-by-step if possible)! TIA Tom L -- View this message in context: http://old.nabble.com/Cygwin-Not-Reading-inittab--tp27300863p27300863.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: Why you can't load ws2_32.dll (was Re: Can't use key authentication on x64 Server 2003 R2)
On 01/08/2010 06:59 AM, Corinna Vinschen wrote: I can't reproduce this one, but I can reproduce the other problem with pubkey authentication reported in this thread: ... I appreciate the time you took to explain this problem. I've been working on it for a while, and still can't get it right. If you're running in a domain, then the account running the sshd service must be a member of the domain as well. Instead of creating a local cyg_server account, you must create a domain account called cyg_server with the specific rights required to create a user token, add it to the /etc/passwd file of the machine on which you want to install sshd, and *then* run ssh-host-config on that machine. I've created a cyg_server account on my domain controller and added it to the password file using: mkpasswd -d -u cyg_server /etc/passwd First I tried granting the required permissions manually in the domain policy. When that didn't work, I used editrights as in cygwin-service-installation-helper.sh to set the rights in the local policy. As far as I can tell, I get identical results. Rights during my most recent test were: $ editrights.exe -l -u cyg_server SeAssignPrimaryTokenPrivilege SeCreateTokenPrivilege SeTcbPrivilege SeServiceLogonRight SeDenyRemoteInteractiveLogonRight If you did that, the ssh-host-config script will note that such an account exists in /etc/passwd and will offer to use that account for the sshd service. Hopefully I did something as simple as adding the account to the password file incorrectly. When I run ssh-host-config, I get the following warning: *** Warning: cyg_server is in /etc/passwd, but the local *** Warning: machine's SAM does not know about cyg_server. *** Warning: Perhaps cyg_server is a pre-existing domain account. *** Warning: Continuing, but check if this is ok. Regardless, I can use the account and sshd will run. When I log in with a password, I get a shell, but I see this warning: 1 [main] sshd 2724 spawn_guts: CreateWindowStation failed, Win32 error 5 If I log in with a key, the server just drops the connection. The (Linux) client reports: Connection closed by 192.168.99.6 The server's event log indicates: The description for Event ID ( 0 ) in Source ( sshd ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: sshd: PID 6632: fatal: seteuid 11287: Permission denied. The event viewer indicates that the user is DOMAIN\cyg_server, which is the same username that appears in the Local Security Settings admin tool. Does anyone have any specific advice for using a domain member account (DOMAIN\cyg_server) to run sshd? Without that, it seems I can't run Cygwin 1.7's sshd with key authentication. -- 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: git stopped working with 1.7.1
I have the same issue trying to clone a repo with a recently updated cygwin. The problem is not present in any other configurations I tried to clone with, including git/ssh built for MSys on the same computer. -- View this message in context: http://old.nabble.com/git-stopped-working-with-1.7.1-tp26905956p27300928.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: FLTK versions in Cygwin [was: Re: units: update, FHS compliance]
On 24/01/2010 18:00, Albrecht Schlosser wrote: I'am aware that -mno-cygwin is no longer supported, but there's nothing we can do until a working gcc-4 cross compiler exists. So long we need to use gcc-3 for Windows/GDI builds (or Cygwin). That's what I'm trying to tell you: -mno-cygwin mean(t) just that: NO cygwin. It shouldn't be the default on Cygwin to not build for Cygwin; after all, you wouldn't have the default on Linux to cross-compile to Win32, would you? If you want to provide the cross-compiling option, that's fine, but it should be an *option*, not the default. Yep, that's what I expected, but didn't check (yet). This may well be changed... It should be, although the workaround is easy in the meantime. I don't know cygport, but I can see one small glitch: Fluid is called fluid[.exe] and not fluid2, as in FLTK 2, and the man page is fluid[.man] and not fluid2. Indeed, I didn't go so far as to run the package phase. (The 1.3 .cygport was basically a copy of the 2.0 .cygport, as they are both snapshots and have more in common than 1.1). Fixed in SVN. 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: Why require ps -W and kill -f
Dave Korn sent the following at Friday, January 22, 2010 6:38 PM On 22/01/2010 21:28, Don Beusee wrote: People don't care about implementation details. They care about what is running on the system (the WHOLE system). You are speaking for yourself. Not everyone in the world. (Larry, please excuse me for continuing.) Don, Let me second that motion. I, for one, do not want the default to be seeing everything on the machine. Do you how many processes that can be? Right now, here's what I get eliminating ps and wc. - ps gives 2 processes. - ps -W gives 27. - Windows Task Manger gives 67. I definitely don't was ps -W as the default. I'd rather not have to adjust scripts or even create an alias for ps. When I want to kill a Windows process, I use Windows tools. When I want to kill a Cygwin process, I use Cygwin tools. Sometimes that doesn't work so I use a Windows tool (Task Manager) to kill a Cygwin process. You are on Windows even though you want to be on Linux. Most everyone on this list can understand what that is like. But the fact of the matter is that you are on a Windows machine. It is impossible to make Windows go away. It is impossible to make Windows behave exactly like Linux. I respectfully suggest that it will be to your advantage to try to learn to live with Windows. Or at least to adjust your expectations of Cygwin. Another point. The Cygwin developers have been using Cygwin for years and years. They also use Linux. Indeed, they include a current and a former employee of Redhat. Trust them. If they tolerate a difference between Cygwin and POSIX or Linux, there is - a good reason for it or - under the circumstances it is better that way or - they just haven't gotten around to working on it. Good luck, - Barry Disclaimer: Statements made herein are not made on behalf of NIAID. -- 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
Blitz++ Package
I'm interested in using blitz++ in a project that I'm working on. I'm using cygwin as my platform and couldn't find the blitz++ package on cygwin. So, a couple of questions. First, am I a complete idiot and miss the package and if so can someone point me to it? Second, if there isn't a current blitz++ package is there any interest in one? I haven't ever put a package together but I figure that if I need to build the library for myself I could at least try and build it for everyone else (assuming there's interest). Thanks. George S. Hugh -- 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: Please support CP932. (I have problem using subversion with SJIS)
2010/1/25 Corinna Vinschen corinna-cyg...@cygwin.com: On Jan 25 01:00, Nayuta Taga wrote: 2010/1/24 Corinna Vinschen corinna-cyg...@cygwin.com: Nayuta, can you please test if the latest from CVS works for you even with LANG=ja_JP.SJIS? Thank you for implementing CP932 and changing SJIS to an alias of CP932. I'll test it tomorrow. Thanks. I can use global-ignores=*~ of Subversion with both ja_JP.SJIS and ja_JP.CP932 . The latest from CVS works as expected. Thank you. -- nayuta -- 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: Fyi Apache2 notes: No space left on device / Cannot create SSLMutex
On Sun, Jan 24, 2010 at 06:02:55PM -0500, Jason Pyeron wrote: From: Christopher Faylor Sent: Sunday, January 24, 2010 15:13 On Sun, Jan 24, 2010 at 02:40:32PM -0500, Jason Pyeron wrote: I restarted apache many times today, just a few minutes ago, it would not start. I am running apache from the command line, and not the cygrunsrv. I do not have time to investigate why this happened, but I might happen to someone else, so here is what I have: jpye...@phoenix /srv/www/cgi-bin $ tail -f /var/log/apache2/error_log This is probably a complete out-of-left-field question but this isn't what is causing the problems with thetvdb.com is it? It's a funny coincidence that this bug report would come in today while thetvdb.com was having similar problems with apache. I did not know anyone else was having any issues. Feel free to have whoever contact me on or off list as appropriate. Going back to my 20 hour Sunday workday now I don't know that this site even uses Cygwin. They'd actually be pretty dumb to use Cygwin's apache on a high-volume site like that so it probably is not the case. I just thought it was an odd coincidence that I read about the same problem from the same netblock in a 60 second window. So, in other words: Nevermind. Just a coincidence. 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: Blitz++ Package
On 2010/01/24 7:07 PM, hughgs wrote: I'm interested in using blitz++ in a project that I'm working on. I'm using cygwin as my platform and couldn't find the blitz++ package on cygwin. So, a couple of questions. First, am I a complete idiot and miss the package and if so can someone point me to it? First check the official package list, here: http://cygwin.com/packages/ If no luck there, you might try checking the list of currently available packages at Cygwin Ports: home page: http://sourceware.org/cygwinports/ package list: ftp://sourceware.org/pub/cygwinports/portslist.txt Second, if there isn't a current blitz++ package is there any interest in one? Well, it's pretty clear there's at least one person interested! And there's no harm in putting it out there, even if there isn't much interest right now. You might end up saving someone some time later on. I haven't ever put a package together but I figure that if I need to build the library for myself I could at least try and build it for everyone else (assuming there's interest). Good thinking. This page seems to be the bible on packaging for Cygwin: http://cygwin.com/setup.html . I've been studying it myself. Best regards, -SM -- -- 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: cppcheck-1.40-1
Version 1.40-1 of cppcheck has been uploaded, following the upstream release. cppcheck is a tool for static C/C++ code analysis. It tries to detect bugs that your C/C++ compiler don't see. The goal is no false positives. cppcheck is versatile. You can check non-standard code that includes various compiler extensions, inline assembly code, etc. *** 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. -- Chris Sutcliffe http://emergedesktop.org
