Re: [ITP] liblzo2/liblzo2_2/liblzo2-devel: A data compression library which is suitable for data de-/compression in real-time
On Mar 17 19:45, Dr. Volker Zell wrote: Corinna Vinschen writes: Packaging looks good. But, do we really need that much ldesc in all packages? I'd suggest to shorten the texts in the liblzo2_2 and liblzo2-devel setup.hint files. Fixed. New files at the old location. Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [GTG] Re: [ITA, RFU] libgcrypt-1.4.0-1
Volker? On Mar 11 15:57, Dr. Volker Zell wrote: Volker Quetschke writes: I just looked into the ImageMagick stuff and I would also like to keep grace. By the way, there is a grace version sitting in test for more than a year now. What about that version ? Ciao Volker Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
[SECURITY] bzip2
Hi Charles, I just read that a security problem which has been found in F-Secure is also a problem for other packages, namely 7zip and bzip2(*). While this is apparently fixed in our 7zip release 4.57 (called 4.5.7 in the below URL), it's only fixed in bzip2 1.0.5. We're still at 1.0.3. Any problem to update? Thanks, Corinna (*) https://www.cert.fi/haavoittuvuudet/joint-advisory-archive-formats.html -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
[RFU] pure-ftpd-1.0.21-2
New configuration script (pure-ftpd-config) was added to simplify NT service creation. The script is based on csih. category: Net requires: cygwin crypt libiconv2 csih sdesc:secure production-quality standard-conformant FTP server ldesc:Pure-FTPd is a fast, secure, production-quality and standard-conformant FTP server. It doesn't provide useless bells and whistles, but focuses on efficiency and ease of use. wget \ http://kacygwinlist.googlepages.com/pure-ftpd-1.0.21-2.tar.bz2 \ http://kacygwinlist.googlepages.com/pure-ftpd-1.0.21-2-src.tar.bz2 \ http://kacygwinlist.googlepages.com/setup.hint
Re: [GTG] Re: [ITA, RFU] libgcrypt-1.4.0-1
Corinna Vinschen wrote: Volker? On Mar 11 15:57, Dr. Volker Zell wrote: Volker Quetschke writes: I just looked into the ImageMagick stuff and I would also like to keep grace. By the way, there is a grace version sitting in test for more than a year now. What about that version ? It is marked test, because it is the test version for the upcoming Grace 6. As the auther still treats it as test, we shouldn't treat it different. (It's unchanged fo a while now) There is actually a newer grace release (5.1.21) and I'll prepare that package once IM is out. Volker Ciao Volker Corinna -- = http://wiki.services.openoffice.org/wiki/Debug_Build_Problems = PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net key-fingerprint 550D F17E B082 A3E9 F913 9E53 3D35 C9BA 9F8A 785D signature.asc Description: OpenPGP digital signature
RE: Suggest upgrading to emacs 22.1.92?
Hmm, I may be wrong. 22.1 just crashed on me. I'm going to try switching back to 22.1.92 and see how long I can run it without crashing. jik -Original Message- From: Jonathan Kamens Sent: Monday, March 17, 2008 6:21 PM To: cygwin-apps@cygwin.com Subject: RE: Suggest upgrading to emacs 22.1.92? I tried recompiling stock Emacs 22.1 with the version of gcc currently in Cygwin. After running it for a couple of days, it didn't crash once. So it seems to me that both 22.1 and 22.1.92 are useable with current gcc and cygwin1.dll. jik
[ITP] aria2-0.13.1+1
Included in debian stable http://packages.debian.org/aria2 category: Net Web requires: cygwin libintl8 libxml2 openssl sdesc:High speed download utility ldesc:Aria2 is a command line download client with resuming and segmented downloading. Supported protocols are HTTP/HTTPS/FTP/BitTorrent and it also supports Metalink. wget \ http://kacygwinlist.fortunecity.com/aria2-0.13.1+1-1.tar.bz2 \ http://kacygwinlist.fortunecity.com/aria2-0.13.1+1-1-src.tar.bz2 \ http://kacygwinlist.fortunecity.com/setup.hint
Re: [RFU] pure-ftpd-1.0.21-2
On Mar 18 18:17, Kostya Altukhov wrote: http://kacygwinlist.googlepages.com/pure-ftpd-1.0.21-2.tar.bz2 \ http://kacygwinlist.googlepages.com/pure-ftpd-1.0.21-2-src.tar.bz2 \ http://kacygwinlist.googlepages.com/setup.hint Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [SECURITY] bzip2
Corinna Vinschen wrote: I just read that a security problem which has been found in F-Secure is also a problem for other packages, namely 7zip and bzip2(*). While this is apparently fixed in our 7zip release 4.57 (called 4.5.7 in the below URL), it's only fixed in bzip2 1.0.5. We're still at 1.0.3. Any problem to update? Updated. I'll update mingw-bzip2 within the next few days. -- Chuck
[ITA] opencdk/libopencdk8: Open Crypto Development Kit
Hi I would like to adopt and maintain the 'opencdk/libopencdk8' packages from Gerrit P.Haase and split them into 'opencdk/libopencdk10/libopencdk-devel' packages. Here are the setup.hint files: --- ./libopencdk10/setup.hint sdesc: Open Crypto Development Kit - (runtime) ldesc: OpenCDK is a library which implements basic parts of the OpenPGP (RFC4880) message format. category: Libs requires: cygwin libgcrypt zlib external-source: opencdk --- ./opencdk-devel/setup.hint sdesc: Open Crypto Development Kit - (development) ldesc: OpenCDK is a library which implements basic parts of the OpenPGP (RFC4880) message format. category: Devel Libs requires: cygwin opencdk10 external-source: opencdk --- ./setup.hint sdesc: Open Crypto Development Kit - (utilities) ldesc: OpenCDK is a library which implements basic parts of the OpenPGP (RFC4880) message format. category: Libs requires: cygwin opencdk10 For downloading cut here #!/bin/bash mkdir -p opencdk/libopencdk10 opencdk/libopencdk-devel cd opencdk wget http://volkerzell.de/cygwin/ITP/opencdk/setup.hint wget http://volkerzell.de/cygwin/ITP/opencdk/opencdk-0.6.6-1-src.tar.bz2 wget http://volkerzell.de/cygwin/ITP/opencdk/opencdk-0.6.6-1.tar.bz2 cd libopencdk10 wget http://volkerzell.de/cygwin/ITP/opencdk/libopencdk10/setup.hint wget http://volkerzell.de/cygwin/ITP/opencdk/libopencdk10/libopencdk10-0.6.6-1.tar.bz2 cd ../libopencdk-devel wget http://volkerzell.de/cygwin/ITP/opencdk/libopencdk-devel/setup.hint wget http://volkerzell.de/cygwin/ITP/opencdk/libopencdk-devel/libopencdk-devel-0.6.6-1.tar.bz2 cut here Ciao Volker
src/winsup/cygwin ChangeLog include/sys/cygwin.h
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2008-03-18 09:57:33 Modified files: winsup/cygwin : ChangeLog winsup/cygwin/include/sys: cygwin.h Log message: * include/sys/cygwin.h: Revert erroneous move of `#ifdef WINVER' to another location. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4064r2=1.4065 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/sys/cygwin.h.diff?cvsroot=srcr1=1.74r2=1.75
[PATCH] better stackdumps
This patch adds the ability to see functions/symbols in the .stackdump
files generated when there's a fault. It parses the export sections of
each loaded module and finds the closest exported address for each stack
frame address. This of course won't be perfect as it will show the
wrong function if the frame is in the middle of a non-exported function,
but it's better than what we have now.
This also uses a couple of tricks to make the output more sensible. It
can see through the sigfe wrappers and print the actual functions
being wrapped. It also has a set of internal symbols that it consults
for symbols in Cygwin. This allows it to get the bottom frame correct
(_dll_crt0_1) even though that function isn't exported. If there are
any other such functions they can be easily added to the 'hints' array.
Also attached is a sample output of an invalid C program and the
resulting stackdump. Note that the frame labeled _sigbe really should
be a frame somewhere inside the main .exe. I pondered trying to extract
the sigbe's return address off the signal stack and using that for the
label but I haven't quite gotten there, since I can't think of a
reliable way to figure out the correct location on the tls stack where
the real return address is stored.
Of course the labeling works for any module/dll, not just cygwin1.dll,
but I didn't have a more elaborate testcase to demonstrate.
Brian2008-03-18 Brian Dessent [EMAIL PROTECTED]
* exceptions.cc (maybe_adjust_va_for_sigfe): New function to cope
with signal wrappers.
(prettyprint_va): New function that attempts to find a symbolic
name for a memory location by walking the export sections of all
modules.
(stackdump): Call it.
* gendef: Mark __sigfe as a global so that its address can be
used by the backtrace code.
* ntdll.h (struct _PEB_LDR_DATA): Declare.
(struct _LDR_MODULE): Declare.
(struct _PEB): Use actual LDR_DATA type for LdrData.
(RtlImageDirectoryEntryToData): Declare.
Index: exceptions.cc
===
RCS file: /cvs/src/src/winsup/cygwin/exceptions.cc,v
retrieving revision 1.319
diff -u -p -r1.319 exceptions.cc
--- exceptions.cc 12 Mar 2008 12:41:49 - 1.319
+++ exceptions.cc 19 Mar 2008 00:04:13 -
@@ -284,6 +284,158 @@ stack_info::walk ()
return 1;
}
+/* These symbols are used by the below functions to put a prettier face
+ on a stack backtrace. */
+extern u_char etext asm (etext); /* End of .text */
+extern u_char _sigfe, _sigbe;
+void dll_crt0_1 (void *);
+
+const struct {
+ DWORD va;
+ const char *label;
+} hints[] = {
+ { (DWORD) _sigbe, _sigbe },
+ { (DWORD) dll_crt0_1, _dll_crt0_1 }
+};
+
+/* Helper function to assist with backtraces. This tries to detect if
+ an entrypoint is really a sigfe wrapper and returns the actual address
+ of the function. Here's an example:
+
+ 610ab9f0 __sigfe_printf:
+ 610ab9f0: 68 40 a4 10 61 push $0x6110a440
+ 610ab9f5: e9 bf eb ff ff jmp610aa5b9 __sigfe
+
+ Suppose that we are passed 0x610ab9f0. We need to recognise the
+ push/jmp combination and return 0x6110a440 _printf instead. Note
+ that this is a relative jump. */
+static DWORD
+maybe_adjust_va_for_sigfe (DWORD va)
+{
+ if (va (DWORD) user_data-hmodule || va (DWORD) etext)
+return va;
+
+ unsigned char *x = (unsigned char *) va;
+
+ if (x[0] == 0x68 x[5] == 0xe9)
+{
+ DWORD jmprel = *(DWORD *)(x + 6);
+
+ if ((unsigned) va + 10 + (unsigned) jmprel == (unsigned) _sigfe)
+return *(DWORD *)(x + 1);
+}
+ return va;
+}
+
+/* Walk the list of modules in the current process and parse their
+ export tables in order to find the entrypoint closest to but less
+ than 'faultva'. This won't be perfect, such as when 'faultva'
+ actually resides in a non-exported function, but it is still better
+ than nothing. Note that this algorithm could be made much more
+ efficient by both sorting the export tables as well as saving the
+ result between calls. However, this implementation requires no
+ allocation of memory and minimal system calls, so it should be safe
+ in the context of an exception handler. And we're probably about to
+ terminate the process anyway, so performance is not critical. */
+static char *
+prettyprint_va (DWORD faultva)
+{
+ static char buf[256];
+
+ ULONG bestmatch_va = 0;
+
+ PLIST_ENTRY head = NtCurrentTeb()-Peb-LdrData-InMemoryOrderModuleList;
+ for (PLIST_ENTRY x = head-Flink; x != head; x = x-Flink)
+{
+ PLDR_MODULE mod = CONTAINING_RECORD (x, LDR_MODULE,
+ InMemoryOrderModuleList);
+ if ((DWORD) mod-BaseAddress faultva)
+continue;
+
+ DWORD len;
+ IMAGE_EXPORT_DIRECTORY *edata_va = (IMAGE_EXPORT_DIRECTORY *)
+ RtlImageDirectoryEntryToData
Re: [PATCH] better stackdumps
Brian Dessent wrote: Of course the labeling works for any module/dll, not just cygwin1.dll, but I didn't have a more elaborate testcase to demonstrate. Forgot to mention... The symbols are just tacked on on the right hand side there for now. I wasn't really sure how to handle that. I didn't want to remove display of the actual EIP for each frame as that could be removing useful info, but I wasn't quite sure where to put everything or how to align it... so as it is now it wraps wider than 80 chars which is probably pretty ugly on a default size terminal. Brian
Re: [PATCH] better stackdumps
Igor Peshansky wrote: Would it make sense to force a newline before the function name and to display it with a small indent? That way people who want the old-style stackdump could just feed the new one into grep -v '^ ' or something... Yes, that would be one way. That actually reminds me of another issue that I forgot to mention: glibc has a backtrace API that can be called from user-code at any time, not just at faults. At the moment we are exporting something similar called cygwin_stackdump but we don't declare it in any header. Would it be worthwhile to try to match the glibc API and export it under the same name/output format? Brian
Re: [PATCH] better stackdumps
On Tue, Mar 18, 2008 at 05:24:20PM -0700, Brian Dessent wrote: This patch adds the ability to see functions/symbols in the .stackdump files generated when there's a fault. It parses the export sections of each loaded module and finds the closest exported address for each stack frame address. This of course won't be perfect as it will show the wrong function if the frame is in the middle of a non-exported function, but it's better than what we have now. This also uses a couple of tricks to make the output more sensible. It can see through the sigfe wrappers and print the actual functions being wrapped. It also has a set of internal symbols that it consults for symbols in Cygwin. This allows it to get the bottom frame correct (_dll_crt0_1) even though that function isn't exported. If there are any other such functions they can be easily added to the 'hints' array. Also attached is a sample output of an invalid C program and the resulting stackdump. Note that the frame labeled _sigbe really should be a frame somewhere inside the main .exe. I pondered trying to extract the sigbe's return address off the signal stack and using that for the label but I haven't quite gotten there, since I can't think of a reliable way to figure out the correct location on the tls stack where the real return address is stored. Of course the labeling works for any module/dll, not just cygwin1.dll, but I didn't have a more elaborate testcase to demonstrate. Brian 2008-03-18 Brian Dessent [EMAIL PROTECTED] * exceptions.cc (maybe_adjust_va_for_sigfe): New function to cope with signal wrappers. (prettyprint_va): New function that attempts to find a symbolic name for a memory location by walking the export sections of all modules. (stackdump): Call it. * gendef: Mark __sigfe as a global so that its address can be used by the backtrace code. * ntdll.h (struct _PEB_LDR_DATA): Declare. (struct _LDR_MODULE): Declare. (struct _PEB): Use actual LDR_DATA type for LdrData. (RtlImageDirectoryEntryToData): Declare. Sorry, but I don't like this concept. This bloats the cygwin DLL for a condition that would be better served by either using gdb or generating a real coredump. OTOH, adding a list of loaded dlls to a stackdump might not be a bad idea so that some postprocessing program could generate the same output as long as that didn't add too much code to cygwin. cgf
Re: Libtool problems when building ImageMagick
Yaakov, On Mar 17 20:56, Yaakov (Cygwin Ports) wrote: NO_LIBTOOLIZE=1 (fix for typo just checked into CVS; use export LIBTOOLIZE=true as a backup until 0.3.9) Yaakov Is there any reason why you don't reply to me on the cygwin-apps mailing list for a month now? http://cygwin.com/ml/cygwin-apps/2008-02/msg00131.html http://cygwin.com/ml/cygwin-apps/2008-02/msg00189.html http://cygwin.com/ml/cygwin-apps/2008-03/msg00059.html http://cygwin.com/ml/cygwin-apps/2008-03/msg00254.html What do I have to do to get your attention? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Strange pthread_atfork() behavior
On Mar 17 22:48, Alon Bar-Lev wrote: When running under cygwin the exec program runs after about 60 seconds. The following is the output: __atfork_prepare __atfork_parent before sleep __atfork_child after sleep parent is not running anymore wait about 60 seconds 56 [main] a 2952 sig_send: wait for sig_complete event failed, signal -34, rc 258, Win32 error 0 at child child output Any clue? Looks like a bug in Cygwin. I ran your testcase and I can reproduce the behaviour on 1.5.25-11. The problem does not occur in current CVS, though, so it seems it has been fixed in CVS at one point. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gmp/mpfr status
On 3/18/08, Tim Prince [EMAIL PROTECTED] wrote: I've been building gcc 4.3 and 4.4 with mpfr upgraded to 2.3.1, taking the gmp provided by cygwin. gcc build doesn't complain about mpfr 2.3.0 until you get to a few testsuite failures, but there seems no point in using less than 2.3.1. The timeline is whenever the mpfr maintainer gets to it. svn HEAD of gcc requires no less than mpfr 2.3.0, or top level configure fails. The current cygwin mpfr is 2.2.1. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Building perl-5.10.0
- Original Message - From: Matthew Persico [EMAIL PROTECTED] . . Well after a bit of googling around, the answer is this: 1) In a Windows cmd command prompt, cd where your cygwin lives - mine is at c:\opt\cygwin Mine is at C:\cygwin. 2) cd .. I first ran 'attrib cygwin' to see what was already there: C:\attrib cygwin C:\cygwin 3) attrib -r cywgin - that removed the read-only bit. Don't try it in Windows Explorer; it does not stick I then ran 'attrib -r cygwin' (even though it doesn't appear to be readonly to begin with). 4) Then in a Cygwin window, cd / 5) chmod 777 . That errors out as follows: [EMAIL PROTECTED] / $ chmod 777 . chmod: changing permissions of `.': Permission denied After all that I get: [EMAIL PROTECTED] / $ ls -alrt total 165 dr-xr-xr-x 1 0 root 0 Jan 1 1970 cygdrive dr-xr-xr-x 1 Rob None 0 Dec 1 2006 proc d---r-x---+ 7 admin Users 0 Mar 12 12:37 var d---r-x---+ 2 admin Users 0 Mar 12 12:37 dev d---r-x---+ 2 admin Users 0 Mar 12 12:37 tmp r-x---+ 1 admin Users 57 Mar 12 12:38 Cygwin.bat drwxrwxrwx+ 3 Rob None 0 Mar 12 12:38 home d---r-x---+ 12 admin Users 4096 Mar 12 12:38 .. d---r-x---+ 12 admin Users 4096 Mar 12 12:38 . d---r-x---+ 11 admin Users 4096 Mar 12 12:50 etc d---r-x---+ 11 admin Users 12288 Mar 12 12:51 lib d---r-x---+ 16 admin Users 4096 Mar 12 12:51 usr d---r-x---+ 2 admin Users 131072 Mar 15 21:20 bin r-x---+ 1 admin Users 7022 Mar 15 21:20 Cygwin.ico and running 'make' terminates as before. This is a fairly new installation of Cygwin, btw. (I stuffed up the old one trying to install rsync and had to delete the lot.) So there could be some additional stuff here that needs sorting out. I have, however, already built some perl extensions using the 5.8.8 build that was installed when I created this fresh build of Cygwin. And the fact that I can build 5.8.8 from source, but not 5.10.0 leads me to wonder whether this is instead a query that should be raised on p5p ? Thanks for the reply, Matthew ... appreciated. Cheers, Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] New: libpq5 (dummy for clisp-2.44-1)
Reini Urban writes: I've uploaded a temporary libpq5-8.2.5-1 package with just the file /bin/cygpq5.dll which is a dependency for the recently uploaded clisp-2.44-1 package. You should not install this package by hand, because it does nothing. The new postgresql-8.2.6 or postgresql-8.3.0 package which will be uploaded soon, will provide the client and server backends and update this temp. libpq5 package. Your uploaded file seems to be libpq5-8.0.7-1.tar.bz2 and not libpq5-8.2.5-1. ?? Ciao Volker -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: postgresql packaging questions
Reini Urban writes: Reini Urban schrieb: 2008/3/6, Dr. Volker Zell [EMAIL PROTECTED]: setup.ini claims the following: @ libecpg-compat1 sdesc: Older version of run-time library for ECPG programs ldesc: The ecpg_compat.dll shared library is used by programs built with ecpg. (Embedded PostgreSQL for C). . PostgreSQL is an object-relational SQL database management system. category: Libs [test] version: 7.4.5-1 @ libecpg4 sdesc: Run-time library for ECPG programs ldesc: The ecpg.dll shared library is used by programs built with ECPG (Embedded PostgreSQL for C). . PostgreSQL is an object-relational SQL database management system. category: Libs requires: libecpg-compat1 [test] version: 7.4.5-1 @ libpgtypes1 sdesc: Shared library pgtypes.dll for PostgreSQL 7.4.x ldesc: The pgtypes shared library is used by programs built with ecpg. (Embedded PostgreSQL for C). . PostgreSQL is an object-relational SQL database management system. category: Libs [test] version: 7.4.5-1 Are these really test versions or actually old dll versions from the post 8.0.7 area ? Right, the [test] looks wrong. I'll check it where this comes from. I have no idea where this was coming from. Should be [prev] Still not fixed Ciao Volker -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Long path name support
Hi, I would like to do what I can to help with this. My reasons are purely selfish; I'm currently having to use Vista and I'd like to get off! I've seen that there is some activity around this [1], [2]. My immediate issue is using rsync fails due to long path names, so that's my motivation for offering to help. I've downloaded the source and had a look, but it's probably beyond my current level of C experience to do much with it. I'm working on fixing that. I was hoping it would be a case of switching out the type-library being used and altering an adaption layer to happily marshall where required to use the *W versions rather than the *A versions but that was a little naive of me. So, how best to help? Trying out the snapshots and seeing whether they work for me, or something else? Are the changes for long path names happening in a branch which I could look at and get an idea of the changes that are required, to submit patches? I've tried just swapping in later snapshots of the cygwin1.dll, but I get GPFs when running bash at the moment, so I'm keen to know what I'm doing wrong there. Cheers, James [1] http://cygwin.com/ml/cygwin/2006-01/msg01275.html [2] http://sourceware.org/ml/cygwin/2007-12/msg00437.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: cygrunsrv-1.34-1
I have updated cygrunsrv to version 1.34-1. This release mainly improves the capability to connect to remote servers introduced with 1.30-1 (see http://cygwin.com/ml/cygwin-announce/2008-03/msg00052.html) The following changes have been made: - When accessing a remote server, cygrunsrv no longer checks the path to the executable for existance, nor does it check if the registry contains required system mount points. - There's a new option -P/--crs-path which allows to specify the path to cygrunsrv. This is especially useful when installing services on a remote machine and the path to cygrunsrv is evaluated incorrectly to run the service correctly on the remote machine. - Erroneous error output when registry access fails has been fixed. - It's now allowed to specify NT user names in the DOMAIN\username syntax also using a forward slash, DOMAIN/username. - A couple of ambiguities in the README file /usr/share/doc/Cygwin/cygrunsrv.README have been fixed. If you have questions or comments, please send them to the Cygwin mailing list at: cygwin@cygwin.com . I would appreciate if you would use this mailing list rather than emailing me directly. This includes ideas and comments about the setup utility or Cygwin in general. If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe to 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: [EMAIL PROTECTED] -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Long path name support
On Mar 18 10:35, James Abley wrote:
I've downloaded the source and had a look, but it's probably beyond my
current level of C experience to do much with it. I'm working on
fixing that. I was hoping it would be a case of switching out the
type-library being used and altering an adaption layer to happily
marshall where required to use the *W versions rather than the *A
versions but that was a little naive of me.
If you have a close look you'll see that the current code is much less
complicated. It uses the NT API as much as possible. The main
difference is that you use UNICODE_STRING and OBJECT_ATTRIBUTES
structures to define files and directories, and that you need Win32 file
names given in WCHAR all the time. Except for this difference, which
makes the code somewhat unusual from the Win32 perspective, the path
handling isn't really more complicated than before. As a bonus, the NT
API allows to specify files or directories in a notation which
is not available on the Win32 level:
file = { directory handle, relative file name }
That comes in handy once in a while.
So, how best to help? Trying out the snapshots and seeing whether they
work for me, or something else?
The best help is testing - debugging - sending patches.
The second best help is testing - debugging - sending simple testcases
in plain C which allow to reproduce the problem plus an idea what's
going wrong.
The third best help is testing - sending simple testcases.
Are the changes for long path names
happening in a branch which I could look at and get an idea of the
changes that are required, to submit patches?
The changes are going on in mainline. The branch is used for the
1.5.x series for some time now.
I've tried just swapping in later snapshots of the cygwin1.dll, but I
get GPFs when running bash at the moment, so I'm keen to know what I'm
doing wrong there.
I just created a snapshot (2008-03-18) which allows to use long
pathnames. Any older snapshot isn't complete on the API level. Even
this latest snapshot is far from complete, but it should basically work.
However, the change to long path names introduces potential
compatibility problems with older applications, which are not problems
in Cygwin per se. PATH_MAX was 260 up to 1.5.25-11. Now it's
4096, but paths returned to applications can be potentially up to 32K(!)
in length. Applications using fixed buffers of size PATH_MAX are bound
to be broken now when used with longer paths.
I'm going to prepare an anouncement for people who like to play with
this snapshot. There are so many changes in the upcoming 1.7 release,
that I need some time to prepare a list which outlines what has changed.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
csih-0.1-1
I get the following when I test my script with auto-answer=yes: *** Info: The following privileged accounts were found: 'cyg_server' . *** Info: This script plans to use 'cyg_server'. *** Info: 'cyg_server' will not be able to log on interactively, but will only *** Info: be used by registered services. *** Query: Do you want to use different name? (yes/no) yes Wouldn't it make more sense to ask the opposite question, e.g. Is it OK to use the suggested name? (yes/no), in that case auto-answer yes would accept the default? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
DLL into .a
Is there a tool to convert a DLL (which has no API Windows calls) into a lib.a or lib.la ? If not, then say that I have a lib file named libmetis.a To make the executable I would add the following -L$HOME/rest of the path -lmetis If I have WinMetis.dll, would there be an equivalent command? Regards, Paulo Mota -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: gmp/mpfr status
From: NightStrike Is there an approximate timeline for when the gmp and mpfr packages will be upgraded to the minimum required for compiling gcc? Really, I guess it's just mpfr that has to be upgraded to 2.3.0., but I think mpfr 2.3.0 requires gmp 4.2.2. I have working packages of gmp-4.2.2 and mpfr-2.3.1. I will try and upload them this weekend. David -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: DLL into .a
Paulo Mota wrote: Is there a tool to convert a DLL (which has no API Windows calls) into a lib.a or lib.la ? That is not possible. A DLL is fully linked code. A static library (libfoo.a) is unlinked code. Linking is a one-way process, it removes information that cannot be recovered. A file named as libfoo.la is a libtool library, and is just a text file of a few lines that describes the options relevant when linking with that library. It alone is useless, it is just metadata. If not, then say that I have a lib file named libmetis.a To make the executable I would add the following -L$HOME/rest of the path -lmetis If I have WinMetis.dll, would there be an equivalent command? Just add WinMetis.dll to the link command line like any other file to be included in the link. You can also create an import library, but that is not necessary unless you need to do symbol aliasing or symbol renaming. This is often necessary when mixing libraries of different compilers due to differences in stdcall name mangling, i.e. you need to remove the @nn decorations. You might be confusing a static library with an import library, as they both end in .a and have the same file format but they are totally different things. An import library (libfoo.dll.a, foo.lib, or occasionally libfoo.a) does not contain any code, but rather just a list of what the actual library (DLL) exports. It is used by the linker when linking to the DLL, but the GNU linker can also link directly to a DLL without the need for an import library -- again as long as you don't need to do any symbol renaming/aliasing. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: csih-0.1-1
Kostya Altukhov wrote: I get the following when I test my script with auto-answer=yes: *** Info: The following privileged accounts were found: 'cyg_server' . *** Info: This script plans to use 'cyg_server'. *** Info: 'cyg_server' will not be able to log on interactively, but will only *** Info: be used by registered services. *** Query: Do you want to use different name? (yes/no) yes Wouldn't it make more sense to ask the opposite question, e.g. Is it OK to use the suggested name? (yes/no), in that case auto-answer yes would accept the default? No, because the most common auto-answer case is when csih-client scripts are invoked by setup, via a postinstall script. In these cases, the auto-answer setting is no. Frankly, I do not believe there should be an auto-answer=yes option at all. It's just too dangerous. However, csih retained it because the original foo-config scripts supported auto-answer-yes, but I do not recommed its use. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] New: libpq5 (dummy for clisp-2.44-1)
2008/3/18, Dr. Volker Zell [EMAIL PROTECTED]: Reini Urban writes: I've uploaded a temporary libpq5-8.2.5-1 package with just the file /bin/cygpq5.dll which is a dependency for the recently uploaded clisp-2.44-1 package. You should not install this package by hand, because it does nothing. The new postgresql-8.2.6 or postgresql-8.3.0 package which will be uploaded soon, will provide the client and server backends and update this temp. libpq5 package. Soon, will be a bit later. I got stuck with a lot of perl and clisp issues, and proper postgresql testing needs some time. Your uploaded file seems to be libpq5-8.0.7-1.tar.bz2 and not libpq5-8.2.5-1. ?? Yes, I was wrong with my idea of providing an empty libpq5-8.2.5-1. I fixed the name when testing again. libpq5-8.0.7-1 is ok for this minor dependency fix. -- Reini -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: perl Tk for cygwin almost fixed
2008/3/17, Michael Kairys [EMAIL PROTECTED]: When you say yet, do you mean someday? :) The reason I ask (and keep asking :) is this: I have been working to port my Perl scripts from AS to Cygwin; and I have them all done except a few that rely on Perl/Tk. In the absense of a Win32-native version I had planned to rewrite them using Win32-GUI, but to be honest I would just as soon not... I really don't know when I will have enough time available for the remaining issues. The patch is there in the tracker, try it out by yourself. And try switching back from unix events to windows events. Reini Urban [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Well, my patch works to pass all tests, but then in real-world apps it fails, due to missing test scripts. I had no time yet, sorry. I hoped Slaven will step in. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gmp/mpfr status
-- From: David Billinghurst [EMAIL PROTECTED] Sent: Tuesday, March 18, 2008 6:35 AM To: cygwin@cygwin.com Subject: RE: gmp/mpfr status From: NightStrike Is there an approximate timeline for when the gmp and mpfr packages will be upgraded to the minimum required for compiling gcc? Really, I guess it's just mpfr that has to be upgraded to 2.3.0., but I think mpfr 2.3.0 requires gmp 4.2.2. I have working packages of gmp-4.2.2 and mpfr-2.3.1. I will try and upload them this weekend. I have been going nuts trying to get gmp 4.2.2 to work. thanks for doing this, David. Much appreciated. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
inetutils-1.5-2 test release
Hi
The test release of inetutils installs fine with setup.
I tested it with my original xinetd setup (replacing the
in.* daemons with the new ones).
---
Authentication via ftpd does not seem to work in the new release:
NEW:
ftp xp.de.oracle.com
Connected to xp.de.oracle.com.
220-
220- Connected to the cygwin ftp server...
220-
220 xp.de.oracle.com FTP server (GNU inetutils 1.5) ready.
Name (xp.de.oracle.com:vzell):
331 Password required for vzell.
Password:
530 Login incorrect.
/bin/ftp: Login failed.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp quit
221 Goodbye.
OLD:
ftp xp.de.oracle.com
Connected to xp.de.oracle.com.
220-
220- Connected to the cygwin ftp server...
220-
220 xp FTP server (GNU inetutils 1.3.2) ready.
Name (xp.de.oracle.com:vzell):
331 Password required for vzell.
Password:
230- ,
__
230-.L_ |
|
230- .gQQQ__ |
|
230- g== |_.---.)
|
230- QQQF= | (^--^)_.- `;
|
230- Q!| ) ee ( |
|
230- | (_.__._) /
|
230- | `--',,'
|
230- ~jjj__, |jgs )_|--')_|
|
230- jj___ |' '
|
230- ~j__ |
|
230- _jj/ | The Hippo says: Welcome to
|
230- .{jjj/~ | _
|
230- .{/` | _ _ _ _ _ (_)
|
230- | / ___)| | | | / _ || | | || ||
_ \ |
230- |( (___ | |_| |( (_| || | | || || |
| ||
230- QL___,| \) \__ | \___ | \___/ |_||_|
|_||
230- QQQL___ |(___/ (|
|
230- 4___ |
|
230- (=Q | -.-. -.-- --. .-- .. -.
|
230-(F=
|__|
230-
230 User vzell logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp 221 Goodbye.
---
Remote commands via the new rsh do not seem to work:
NEW
rsh [EMAIL PROTECTED] ls
/bin/rsh: must be setuid root.
OLD:
rsh [EMAIL PROTECTED] ls
1016989963.dat
1016989963.phb
AddrBook.Dat
Calendar
:
:
-
Last question. What is .talkrc for ? I get the following in
/var/log/messages when running talk. The man page says nothing.
Mar 18 13:30:37 localhost talkd: PID 2132: can't open config file
/home/vzell/.talkrc: No such file or directory
Ciao
Volker
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: gmp/mpfr status
Bobby McNulty wrote: I have been going nuts trying to get gmp 4.2.2 to work. thanks for doing this, David. Much appreciated. What in the world are you doing that's causing so much trouble? They always have built out of the box with default options just fine for me, including 2.3.1 and 4.2.2 which pass all checks. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gmp/mpfr status
Bobby McNulty wrote: It built fine. Installed. Got to build mpfr 2.31, and gmp 4.2.2 kept showing 4.2.1. That's because toplevel configure will find the system gmp header in /usr/include unless you pass --with-gmp=prefix you built gmp with and --with-mpfr=prefix you built mpfr with. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gmp/mpfr status
- Original Message - From: Brian Dessent [EMAIL PROTECTED] To: cygwin@cygwin.com Sent: Tuesday, March 18, 2008 9:33 AM Subject: Re: gmp/mpfr status Bobby McNulty wrote: I have been going nuts trying to get gmp 4.2.2 to work. thanks for doing this, David. Much appreciated. What in the world are you doing that's causing so much trouble? They always have built out of the box with default options just fine for me, including 2.3.1 and 4.2.2 which pass all checks. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ It built fine. Installed. Got to build mpfr 2.31, and gmp 4.2.2 kept showing 4.2.1. I did something wrong in installing it. not sure where. Waiting on Service pack 1 for Vista. See you guys later. BTW Cygwin works great under Vista Home Premium. All I did to install it under my semi-admin account was: 1 turn off UAC 2 rename setup.exe to foo 3 execute. Takes me about 45 minutes it install from the net. But with it downloaded, with Jari's programs, take 20 minutes from to install from hard drive. With Vista, I made a 30 GB partition, and everything I download off the net goes there. Including Cygwin. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gmp/mpfr status
- Original Message - From: Brian Dessent [EMAIL PROTECTED] To: cygwin@cygwin.com Sent: Tuesday, March 18, 2008 9:55 AM Subject: Re: gmp/mpfr status Bobby McNulty wrote: It built fine. Installed. Got to build mpfr 2.31, and gmp 4.2.2 kept showing 4.2.1. That's because toplevel configure will find the system gmp header in /usr/include unless you pass --with-gmp=prefix you built gmp with and --with-mpfr=prefix you built mpfr with. Brian I will till this weekend to get the correct pair. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gmp/mpfr status
Bobby McNulty wrote: It built fine. Installed. Got to build mpfr 2.31, and gmp 4.2.2 kept showing 4.2.1. That's because toplevel configure will find the system gmp header in /usr/include unless you pass --with-gmp=prefix you built gmp with and --with-mpfr=prefix you built mpfr with. Brian -- Thanks for the info, BTW. Forgot about that. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: please help: crash on vista
Hi Dave, hi Cygwin developers, I checked the contents of /proc/pid/maps with the test program below, both before and after waveinopen, with both cygwin1.dll 1.5.25.11 and the snapshot 2008-03-02. The content of maps seems to be the same, with some differences in the permissions. The test program is at the end of this post. 1.5.25.11 crashes almost immediately after returning from waveinopen (I had to try many times to get the /proc/pid/maps). waveinopen returns 0 (no error). snapshot runs without problems. contents of /proc/pid/maps in cygwin 1.5.25.11: === 1.5.25.11 BEFORE waveinopen: 0040-0046 r--s 00401000 56BD:822F 27021597764369322 /home/maruzz/wavein/waveinopen_vista.exe 777D-778EE000 rw-s 56BD:822F 281474976736141 /cygdrive/c/Windows/system32/ntdll.dll 776F-777C8000 r-xs 7773B6EC 56BD:822F 281474976735614 /cygdrive/c/Windows/system32/kernel32.dll 6100-6120 r--s 610547B0 56BD:822F 3377699720531033 /usr/bin/cygwin1.dll 7643-764EF000 r-xs 764773B4 56BD:822F 281474976734517 /cygdrive/c/Windows/system32/ADVAPI32.DLL 7736-77423000 r-xs 773AAB44 56BD:822F 1407374883561411 /cygdrive/c/Windows/system32/RPCRT4.dll 7229-722C3000 r-xs 72293841 56BD:822F 281474976736981 /cygdrive/c/Windows/system32/WINMM.DLL 770A-7714A000 r-xs 770AA66D 56BD:822F 281474976735930 /cygdrive/c/Windows/system32/msvcrt.dll 7797-77A0E000 r-xs 77984205 56BD:822F 562949953467980 /cygdrive/c/Windows/system32/USER32.dll 7728-772CB000 r-xs 77289339 56BD:822F 281474976735244 /cygdrive/c/Windows/system32/GDI32.dll 7626-763A4000 r-xs 762B7EC1 56BD:822F 281474976736212 /cygdrive/c/Windows/system32/ole32.dll 7766-776EC000 r--s 77664307 56BD:822F 1125899906896537 /cygdrive/c/Windows/system32/OLEAUT32.dll 7225-72288000 r-xs 72251C6D 56BD:822F 281474976736214 /cygdrive/c/Windows/system32/OLEACC.dll 7743-7744E000 r-xs 7743134D 56BD:822F 281474976735375 /cygdrive/c/Windows/system32/IMM32.DLL 7716-77227000 r-xs 771616B9 56BD:822F 281474976735811 /cygdrive/c/Windows/system32/MSCTF.dll 7765-77659000 r--s 77651303 56BD:822F 281474976735683 /cygdrive/c/Windows/system32/LPK.DLL 763B-7642D000 r--s 763C76EE 56BD:822F 281474976736835 /cygdrive/c/Windows/system32/USP10.dll 75EC-75EEC000 r-xs 75EC1275 56BD:822F 281474976734536 /cygdrive/c/Windows/system32/apphelp.dll = 1.5.25.11 AFTER waveinopen: 0040-0046 rw-p 00401000 56BD:822F 27021597764369322 /home/maruzz/wavein/waveinopen_vista.exe 777D-778EE000 r-xs 56BD:822F 281474976736141 /cygdrive/c/Windows/system32/ntdll.dll 776F-777C8000 r-xs 7773B6EC 56BD:822F 281474976735614 /cygdrive/c/Windows/system32/kernel32.dll 6100-6120 rw-p 610547B0 56BD:822F 3377699720531033 /usr/bin/cygwin1.dll 7643-764EF000 r-xs 764773B4 56BD:822F 281474976734517 /cygdrive/c/Windows/system32/ADVAPI32.DLL 7736-77423000 r-xs 773AAB44 56BD:822F 1407374883561411 /cygdrive/c/Windows/system32/RPCRT4.dll 7229-722C3000 r-xs 72293841 56BD:822F 281474976736981 /cygdrive/c/Windows/system32/WINMM.DLL 770A-7714A000 r--s 770AA66D 56BD:822F 281474976735930 /cygdrive/c/Windows/system32/msvcrt.dll 7797-77A0E000 r-xs 77984205 56BD:822F 562949953467980 /cygdrive/c/Windows/system32/USER32.dll 7728-772CB000 r-xs 77289339 56BD:822F 281474976735244 /cygdrive/c/Windows/system32/GDI32.dll 7626-763A4000 r-xs 762B7EC1 56BD:822F 281474976736212 /cygdrive/c/Windows/system32/ole32.dll 7766-776EC000 r--s 77664307 56BD:822F 1125899906896537 /cygdrive/c/Windows/system32/OLEAUT32.dll 7225-72288000 r-xs 72251C6D 56BD:822F 281474976736214 /cygdrive/c/Windows/system32/OLEACC.dll 7743-7744E000 r-xp 7743134D 56BD:822F 281474976735375 /cygdrive/c/Windows/system32/IMM32.DLL 7716-77227000 r-xs 771616B9 56BD:822F 281474976735811 /cygdrive/c/Windows/system32/MSCTF.dll 7765-77659000 r--s 77651303 56BD:822F 281474976735683 /cygdrive/c/Windows/system32/LPK.DLL 763B-7642D000 r--s 763C76EE 56BD:822F 281474976736835 /cygdrive/c/Windows/system32/USP10.dll 75EC-75EEC000 rw-p 75EC1275 56BD:822F 281474976734536 /cygdrive/c/Windows/system32/apphelp.dll 721C-721F r-xs 721C3E73 56BD:822F 281474976736903 /cygdrive/c/Windows/system32/wdmaud.drv 727A-727A4000 r-xp 727A1030 56BD:822F 281474976735633 /cygdrive/c/Windows/system32/ksuser.dll 7530-75307000 r--s 75301080 56BD:822F 281474976734586 /cygdrive/c/Windows/system32/AVRT.dll 7523-75257000 r-xs 7523A4EE 56BD:822F 562949953460253 /cygdrive/c/Windows/system32/MMDevAPI.DLL 7730-77355000 r-xs 77318C95 56BD:822F 281474976736572 /cygdrive/c/Windows/system32/SHLWAPI.dll 74E3-74FC4000 rw-s 74E963D1 56BD:822F 281474976756316 /cygdrive/c/Windows/WinSxS/x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6000.16386_none_5d07289e07e1d100/comctl32.dll 7701-77094000 r-xs 77012469 56BD:822F 281474976734696
[ANNOUNCEMENT] Updated: libtool1.5-1.5.25a-1, libltdl3-1.5.25a-1
GNU libtool is a generic library support script. Libtool hides the complexity of using shared libraries behind a consistent, portable interface. This is a routine update to one of the more recent releases from the 1.5 branch. It has been available from the mirrors since last July, and as an official cygwin test release since January. (The actual latest release from that branch at this time is 1.5.26 but it has not been tested thoroughly enough on cygwin). While the upstream libtool team has released libtool-2.2, there are still a few issues that preclude an official cygwin package. These have been resolved in libtool CVS, so I expect to release an official cygwin libtool2.2 package once the upstream team releases version 2.2.2. Be forewarned, however, that libtool1.5 and libtool2.2 cannot coexist in the same installation tree (that is, with the same prefix=/usr) -- so official cygwin packages of libtool1.5 and libtool2.2 cannot both be installed at the same time. -- Chuck To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** 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: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
downgrade to cygwin-1.5.24-2
Hi. I'm facing some problems with Cygwin 1.5.25.11 under Windows Vista, the most annonying is puttycyg not working anymore.. So I realized that I need to downgrade to the last version supported by puttycyg (http://web.gccaz.edu/~medgar/puttycyg/) The thing is. No previous versions of cygwin are available for install. So how can I downgrade my current (and latest) Cygwin version to the earlier 1.5.24-2 ? Best regards! Gaston -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: inetutils-1.5-2 test release
The test release of inetutils installs fine with setup. I tested it with my original xinetd setup (replacing the in.* daemons with the new ones). Authentication via ftpd does not seem to work in the new release: ... 530 Login incorrect. This is odd. ftpd works for me 1) on XP SP2, where inetd is installed as a service on its own, running under the local system account 2) on XP SP2, where inetd is installed as a service using cygrunsrv, running under the local system account 3) on XP SP2, where inetd is invoked via sysvinit's init process (/etc/rc.d/inetd), and were init is running under the local system account However, ftpd does not work if inetd is running under sshd_server/cyg_server/other_privileged_user -- so I assume it will not yet work under vista. But that issue is not a regression, AFAICT. What are the details of your installation? I don't need full cygcheck, just OS ver, user that inetd is running as, whether inetd is installed as a service on its own, under cygrunsrv, or via sysvinit's init service (and the user under which init is running), and an `ls -l' listing of /etc. Remote commands via the new rsh do not seem to work: rsh [EMAIL PROTECTED] ls /bin/rsh: must be setuid root. Hm. again, this works for me -- unless inetd is running under a privileged user. This is because rshd contains code to check the UID (against '18' == LocalSystem; it doesn't know how to deal with other privileged UIDs. But again -- the old rshd had the same limitation in the code, so I am a bit confused as to how it worked for you, before. Unless xinetd was running under LocalSystem, but inetd is not? Last question. What is .talkrc for ? I get the following in /var/log/messages when running talk. The man page says nothing. Mar 18 13:30:37 localhost talkd: PID 2132: can't open config file /home/vzell/.talkrc: No such file or directory You're right, this is not documented at all. 2001-10-25 Sergey Poznyakoff Talkd essencially rewritten. New feature: system-wide and user-specific access-control lists allow for controlling who and from where is able to request talks. Somebody also mentioned that error message (note the date): http://lists.gnu.org/archive/html/bug-inetutils/2002-09/msg00037.html but it was never corrected. Anyway, it seems that .talkrc is intended for per-user access control, like the `talkd --acl FILE' option is for site-wide access control. -a, --acl FILE read site-wide ACLs from FILE The format of the site-wide acl file and the per-user acl file is the same -- because it is parsed by the same code. However, the format isn't documented at all, either. Perusing the code, it looks like the format is: allow|deny RE INET [INET [INET ...] where one of allow/deny is required RE is a regular expression (regcomp() style) that is applied to the caller's username. Whether Extended RE patterns are allowed depends on the system implementation of regcomp. INET is a network address. It appears that any of these formats work: 192.168.1.0/255.255.255.0 192.168.1.0/24 192.168.1.2 any but no dns lookups are possible. Both RE and (one of the) INET have to match for the specified rule (allow or deny) to apply. The default behavior is: allow * any I'll look into silencing that error message. BTW, I hadn't even gotten around to announcing this as an official test release yet. You're really on the ball... -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: downgrade to cygwin-1.5.24-2
Gaston Martin wrote: The thing is. No previous versions of cygwin are available for install. So No, there's always one previous version available, in this case 1.5.25-7. how can I downgrade my current (and latest) Cygwin version to the earlier 1.5.24-2 ? a) Check the directory of your favorite mirror, most keep more than just the prev/curr versions. b) Build it from source yourself. c) Use the Cygwin time machine site. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: downgrade to cygwin-1.5.24-2
Gaston Martin wrote: Hi. I'm facing some problems with Cygwin 1.5.25.11 under Windows Vista, the most annonying is puttycyg not working anymore.. So I realized that I need to downgrade to the last version supported by puttycyg (http://web.gccaz.edu/~medgar/puttycyg/) It would probably be more appropriate to say the last known working version of cygwin1.dll with puttycyg, since Cygwin 1.5.x is backward-compatible with older versions. Have you reported the problem to the list (see http://cygwin.com/problems.html)? Doing so could make your need for an old, unsupported version of the DLL moot. The thing is. No previous versions of cygwin are available for install. So how can I downgrade my current (and latest) Cygwin version to the earlier 1.5.24-2 ? Current mirrors should have this. Your local download directory might have it too. If it does, just tell 'setup.exe' to install from your local directory and 1.5.24-2 will show up as an option. If you don't have it in your local download directory, use 'wget' or your other favorite tool to download it from a mirror and put it in your local download directory. There's also the Cygwin Time Machine (google it). Note that neither process for installing old DLLs is recommended and the older versions are not supported by this list. -- 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? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: downgrade to cygwin-1.5.24-2
Gaston Martin wrote on 18 March 2008 16:07: Hi. I'm facing some problems with Cygwin 1.5.25.11 under Windows Vista, the most annonying is puttycyg not working anymore.. So I realized that I need to downgrade to the last version supported by puttycyg (http://web.gccaz.edu/~medgar/puttycyg/) The thing is. No previous versions of cygwin are available for install. So how can I downgrade my current (and latest) Cygwin version to the earlier 1.5.24-2 ? Google the list archives for cygwin time machine. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: inetutils-1.5-2 test release
On Mar 18 12:32, Charles Wilson wrote: The test release of inetutils installs fine with setup. I tested it with my original xinetd setup (replacing the in.* daemons with the new ones). Authentication via ftpd does not seem to work in the new release: ... 530 Login incorrect. This is odd. ftpd works for me 1) on XP SP2, where inetd is installed as a service on its own, running under the local system account 2) on XP SP2, where inetd is installed as a service using cygrunsrv, running under the local system account 3) on XP SP2, where inetd is invoked via sysvinit's init process (/etc/rc.d/inetd), and were init is running under the local system account However, ftpd does not work if inetd is running under sshd_server/cyg_server/other_privileged_user -- so I assume it will not yet work under vista. But that issue is not a regression, AFAICT. What are the details of your installation? That is a regression, afaics. The privileged account needs the specific user privileges to change the user context, but if it has these privileges, it should behave not different than when running under the SYSTEM account in earlier versions of Windows. The old ftpd doesn't test the uid for being any fixed value. Same for inetd. Hm. again, this works for me -- unless inetd is running under a privileged user. This is because rshd contains code to check the UID (against '18' == LocalSystem; it doesn't know how to deal with other privileged UIDs. But again -- the old rshd had the same limitation in the code, Uh, no. the old rshd has this in the code: #ifdef __CYGWIN__ uid_t ROOT_UID = getuid (); #else ROOT_UID (0) #endif Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: inetutils-1.5-2 test release
Charles Wilson writes: The test release of inetutils installs fine with setup. I tested it with my original xinetd setup (replacing the in.* daemons with the new ones). Authentication via ftpd does not seem to work in the new release: ... 530 Login incorrect. This is odd. ftpd works for me 1) on XP SP2, where inetd is installed as a service on its own, running under the local system account 2) on XP SP2, where inetd is installed as a service using cygrunsrv, running under the local system account 3) on XP SP2, where inetd is invoked via sysvinit's init process (/etc/rc.d/inetd), and were init is running under the local system account However, ftpd does not work if inetd is running under sshd_server/cyg_server/other_privileged_user -- so I assume it will not yet work under vista. But that issue is not a regression, AFAICT. What are the details of your installation? I don't need full cygcheck, just OS ver, user that inetd is running as, whether inetd is installed as a service on its own, under cygrunsrv, or via sysvinit's init service (and the user under which init is running), and an `ls -l' listing of /etc. OS: XP SP2 I was running xinetd with my previous tests (but checked now inetd and it is the same) with your option 3) under Local System account. 06:41 PM [632] ls -l total 619 -rw-r--r-- 1 vzell users4279 Nov 13 01:00 DIR_COLORS -rw-r--r-- 1 vzell admin5689 Mar 18 18:30 Descript.ion -rw-r--r-- 1 vzell admin 588 Feb 20 2006 GeoIP.conf -rw-r--r-- 1 vzell users 87738 Aug 23 2007 Muttrc lrwxrwxrwx 1 vzell admin 17 May 21 2007 TIMEZONE - /etc/default/init drwxr-xr-x+ 2 vzell admin 0 Jul 24 2007 WindowMaker/ drwxr-xr-x+ 14 vzell admin 0 Feb 12 15:41 X11/ -rw-r--r-- 1 vzell admin2557 Aug 22 2003 a2ps-site.cfg -rw-r--r-- 1 vzell admin 15071 Aug 22 2003 a2ps.cfg -rw-r--r-- 1 vzell admin 18 Jan 3 2003 aliases drwxr-xr-x+ 2 vzell admin 0 Feb 20 14:36 alternatives/ drwxr-xr-x+ 2 vzell admin 0 Jul 24 2007 apache/ drwxr-xr-x+ 5 vzell admin 0 Feb 17 18:10 apache2/ drwxr-xr-x+ 7 vzell users 0 Feb 12 14:58 asciidoc/ -rw-r--r-- 1 vzell admin 144 Jan 2 2003 at.deny -rw-r--r-- 1 vzell admin 301 Feb 2 2006 bash.bashrc -rw-r--r-- 1 vzell admin 215739 Oct 30 2006 bash_completion drwxr-xr-x+ 2 vzell admin 0 Nov 13 00:52 bash_completion.d/ drwxr-xr-x+ 2 vzell admin 0 Jul 24 2007 bonobo-activation/ drwxr-xr-x+ 2 vzell users 0 Nov 13 01:00 boxes/ -rw-r--r-- 1 vzell users 32 Nov 13 01:00 brlapi.key drwxr-xr-x+ 2 vzell users 0 Nov 13 00:25 brltty/ -rw-r--r-- 1 vzell users 15747 Nov 13 01:00 brltty.conf -rw-r--r-- 1 vzell admin7658 Oct 24 2004 clamd.conf -rw-r--r-- 1 vzell admin 844 Feb 22 13:03 colordiffrc drwxr-xr-x+ 2 vzell admin 0 Jul 24 2007 cron.d/ -rw-r--r-- 1 vzell admin1714 Jun 10 2007 csh.cshrc -rw-r--r-- 1 vzell admin 428 Jun 10 2007 csh.login -rw-r--r-- 1 vzell admin1471 Dec 9 2006 cygport.conf -rw-r--r-- 1 vzell admin5138 Jan 5 19:48 cygserver.conf drwxr-xr-x+ 2 vzell admin 0 Jul 24 2007 default/ drwxr-xr-x+ 4 vzell admin 0 Nov 13 00:52 defaults/ drwxr-xr-x+ 3 vzell admin 0 Jul 24 2007 dpkg/ drwxr-xr-x+ 2 vzell users 0 Nov 13 01:00 email/ -rw-r--r-- 1 vzell admin4868 Dec 16 13:03 enscript.cfg -rw-r--r-- 1 vzell admin 153 Aug 22 2005 esd.conf -rw-r--r-- 1 system root22992 Jan 13 2007 exim.conf drwxr-xr-x+ 4 vzell admin 0 Jul 24 2007 fonts/ -rw-r--r-- 1 vzell admin1497 Sep 17 2004 freshclam.conf -rw-r--r-- 1 vzell admin 14 Mar 5 02:54 ftpusers -rw-r--r-- 1 vzell admin 40 Mar 5 02:54 ftpwelcome drwxr-xr-x+ 6 vzell admin 0 Jul 24 2007 gconf/ drwxr-xr-x+ 3 vzell admin 0 Jul 24 2007 ggi/ drwxr-xr-x+ 3 vzell admin 0 Jul 24 2007 gnome-vfs-2.0/ -rw-r--r-- 1 vzell admin 10793 Aug 2 2005 gnome-vfs-mime-magic -rw-r--r-- 1 vzell admin 481 Feb 27 13:34 group drwxr-xr-x+ 2 vzell admin 0 Jul 24 2007 gtk/ drwxr-xr-x+ 2 vzell admin 0 Jul 24 2007 gtk-2.0/ lrwxrwxrwx 1 vzell admin 37 Aug 1 2005 hosts - C:\WINDOWS\system32\drivers\etc\hosts* -rw-r--r-- 1 vzell admin 200 Dec 10 2002 hosts.allow -rw-r--r-- 1 vzell admin 407 Dec 10 2002 hosts.deny -rw-r--r-- 1 vzell admin 64 Feb 21 13:57 hosts.equiv drwxr-xr-x+ 2 vzell admin 0 Jul 24 2007 imlib/ -rw-r--r-- 1 vzell admin2668 Mar 18 18:00 inetd.conf -rw-r--r-- 1 vzell admin2061 Dec 4 2003 inetd.conf.ok drwxr-xr-x+ 2 vzell users 0 Mar 18 11:39 inetd.d/ -rw-r--r-- 1 vzell admin1678 Feb 20 12:48 inittab -rw-r--r--+ 1 vzell admin 44 Feb 27 14:03 ioctl.save -rw-r--r-- 1 vzell admin5651 Feb 15 17:20
Re: inetutils-1.5-2 test release
Corinna Vinschen wrote: On Mar 18 12:32, Charles Wilson wrote: This is odd. ftpd works for me 1) on XP SP2, where inetd is installed as a service on its own, running under the local system account 2) on XP SP2, where inetd is installed as a service using cygrunsrv, running under the local system account 3) on XP SP2, where inetd is invoked via sysvinit's init process (/etc/rc.d/inetd), and were init is running under the local system account However, ftpd does not work if inetd is running under sshd_server/cyg_server/other_privileged_user -- so I assume it will not yet work under vista. But that issue is not a regression, AFAICT. What are the details of your installation? That is a regression, afaics. The privileged account needs the specific user privileges to change the user context, but if it has these privileges, it should behave not different than when running under the SYSTEM account in earlier versions of Windows. The old ftpd doesn't test the uid for being any fixed value. ftp was the worst as far as porting changes from 1.3.2-X to 1.5. LOTS of stuff. It is entirely possible that I (a) missed something in forward porting old modifications, or (b) there was some new code in 1.5 that needed modification and I missed that. That's why this is a test release. It works for me, but I've only got the one computer (* okay, I just got a vista machine last week, but I haven't even tried to install cygwin on it. Reading the horror stories...) Same for inetd. Right. I had no issues with inetd *itself*, running under the cyg_server (or sshd_server) account. It was (some of) the slave daemons that were troublesome -- but not all. telnetd works (for me), for instance. I remember that at least one of the r* cmds worked (for me), too -- except that unless LocalServer, .rhosts were not honored. Uh, no. the old rshd has this in the code: #ifdef __CYGWIN__ uid_t ROOT_UID = getuid (); #else ROOT_UID (0) #endif Oops. I was thinking of rlogind: #define ROOT_UID18 -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: inetutils-1.5-2 test release
On Mar 18 13:46, Charles Wilson wrote: (* okay, I just got a vista machine last week, but I haven't even tried to install cygwin on it. Reading the horror stories...) diabolical laughter Oops. I was thinking of rlogind: #define ROOT_UID18 Uh oh. There's a certain chance that I never tested that on post-XP either... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
FAQ suggestion
The last company I worked for tried bundling Cygwin (with sources, natch) as part of a product. Predictably (to those who have tried this), this caused big problems because it conflicted with any Cygwin installed on customers' machines. Looking at the archives, I see at least a couple other people have tried to do this, e.g. http://www.cygwin.com/ml/cygwin/2001-10/msg00625.html http://www.cygwin.com/ml/cygwin/2001-10/msg00650.html http://www.cygwin.com/ml/cygwin/2007-03/msg00862.html but the Cygwin developers always reply with Don't do that. There can be only one instance of cygwin. I'd like to see an FAQ entry about this, e.g. http://cygwin.com/faq/faq.programming.html#faq.bundled.cygwin --- snip -- Q. I want to bundle Cygwin with a product, and ship it to customer sites. How can I do this without conflicting with any Cygwin installed by the user? A. Cygwin is not designed for this; the developers official position is that there should be only one instance of cygwin on any system, and that it should be updated to the latest version constantly. So please don't try. It will only bring you grief. What, you're still here? Move on to the next question, nothing to see here. Oh, ok. If you want to do it anyway, one way to do it is to change four places in the Cygwin source tree and rebuild from scratch, then ship both source and binary of Cygwin with your product. The four places are: - change the updater to point to your own update server, or disable it - change the name of the shared/common memory area - change the location in the registry where Cygwin settings are kept - rename the cygwin1.dll (such that all apps you build know the new name) It's a daunting prospect. One can imagine a shell script that automates producing such a modified version of Cygwin, but nobody has written one yet. --- snip --- How's that look? Corrections welcome. - Dan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FAQ suggestion
On Tue, Mar 18, 2008 at 02:15:58PM -0700, Dan Kegel wrote: The last company I worked for tried bundling Cygwin (with sources, natch) as part of a product. Predictably (to those who have tried this), this caused big problems because it conflicted with any Cygwin installed on customers' machines. Looking at the archives, I see at least a couple other people have tried to do this, e.g. http://www.cygwin.com/ml/cygwin/2001-10/msg00625.html http://www.cygwin.com/ml/cygwin/2001-10/msg00650.html http://www.cygwin.com/ml/cygwin/2007-03/msg00862.html but the Cygwin developers always reply with Don't do that. There can be only one instance of cygwin. I'd like to see an FAQ entry about this, e.g. http://cygwin.com/faq/faq.programming.html#faq.bundled.cygwin --- snip -- Q. I want to bundle Cygwin with a product, and ship it to customer sites. How can I do this without conflicting with any Cygwin installed by the user? A. Cygwin is not designed for this; the developers official position is that there should be only one instance of cygwin on any system, and that it should be updated to the latest version constantly. So please don't try. It will only bring you grief. What, you're still here? Move on to the next question, nothing to see here. Oh, ok. If you want to do it anyway, one way to do it is to change four places in the Cygwin source tree and rebuild from scratch, then ship both source and binary of Cygwin with your product. The four places are: - change the updater to point to your own update server, or disable it - change the name of the shared/common memory area - change the location in the registry where Cygwin settings are kept - rename the cygwin1.dll (such that all apps you build know the new name) It's a daunting prospect. One can imagine a shell script that automates producing such a modified version of Cygwin, but nobody has written one yet. --- snip --- How's that look? Corrections welcome. You somehow managed to get part of the message while tanking on the rest. We're not going to TELL people that it's ok to make random changes to the source. That is not true. We're not going to imply in any way that keeping multiple copies around is sanctioned by giving instructions. Your instructions are incomplete and imprecise. But, then, they always are. And, they probably always will be because no one would be compelled to update them if/when Corinna or I make changes to the Cygwin sources. So, we DON'T WANT people doing this. What we actually want a 3PP to do is check if there is a version of cygwin installed and use the installed version if it is a newer or conditionally upgrade if it is not. If someone wrote a nice utility for doing this type of checking, I'd be happy to put it somewhere on the Cygwin site. We're not going to tell people that it's ok to keep multiple copies around because that just isn't true. Yes, I know. It's horribly inconvenient for those people who really want to make a buck by bundling this totally free software with their apps. And, maybe the 3PP just wants one or two cygwin utilities and what's the big deal and *you* made the changes to the source and everything (seemed to) work just fine and maybe it's time to think about this because it's been a problem for so long and cygwin will die a horrible screaming painful death if something isn't done very soon. Still not gonna happen. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Emacs-23.0.60.snapshot (20080315) Cygwin binaries
Angelo Graziosi wrote: Non-official Cygwin binaries can be found here http://www.webalice.it/angelo.graziosi/cygwin/emacs/Emacs.html To install see the emacs-23.0.60.snapshot.README file. Thanks! This is great. Will this make it to the official repositories soon? -Lewis -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FAQ suggestion
[EMAIL PROTECTED] wrote: You somehow managed to get part of the message while tanking on the rest. OK, how's this look: Q. I want to bundle Cygwin with a product, and ship it to customer sites. How can I do this without conflicting with any Cygwin installed by the user? A. Cygwin is not designed for this. Please don't try. Third party developers who wish to use Cygwin should check if there is a version of cygwin installed and use the installed version if it is a newer, or conditionally upgrade if it is not. If someone wrote a nice utility for doing this type of checking, the Cygwin developers would be happy to put it somewhere on the Cygwin site. Yes, I know. It's horribly inconvenient for those people who really want to make a buck by bundling this totally free software with their apps. And, maybe the 3PP just wants one or two cygwin utilities and what's the big deal and *you* made the changes to the source and everything (seemed to) work just fine and maybe it's time to think about this because it's been a problem for so long and cygwin will die a horrible screaming painful death if something isn't done very soon. Oh, c'mon, don't hold back; how do you really feel about it? - Dan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FAQ suggestion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Dan Kegel on 3/18/2008 6:15 PM: | [EMAIL PROTECTED] wrote: | You somehow managed to get part of the message while tanking on the rest. | | OK, how's this look: | | Q. I want to bundle Cygwin with a product, and ship it to customer | sites. How can I do this without conflicting with any Cygwin | installed by the user? | | A. Cygwin is not designed for this. Please don't try. | Third party developers who wish to use Cygwin should check if | there is a version of cygwin installed and use the installed | version if it is a newer, or conditionally upgrade if it is not. | If someone wrote a nice utility for doing this type of checking, | the Cygwin developers would be happy to put it somewhere on | the Cygwin site. That sounds better. But it is still lacking an important piece of information, which too many 3PP overlook: Also, remember that by distributing your project which depends on cygwin, you are bound by the license agreement, http://cygwin.com/licensing.html. ~ Your application must either be under the GPL, or you must purchase a support contract through Red Hat; and if you choose to distribute cygwin1.dll, you must also ensure that you provide the cygwin source code that matches what you distribute. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkfgXU0ACgkQ84KuGfSFAYDmpACfUwRL1CxEwpjvl8jgY5GlbqJe 4MgAnA5/ewHk4MZony6fS/8gymfOXfkb =1YCz -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FAQ suggestion
On 18/03/2008, Christopher Faylor [EMAIL PROTECTED] wrote: So, we DON'T WANT people doing this. What we actually want a 3PP to do is check if there is a version of cygwin installed and use the installed version if it is a newer or conditionally upgrade if it is not. The problem with this is that it requires the immediate and total cooperation of all 3PPs. Sure - Acme Software might change their application to check for a pre-existing instance of Cygwin, and let's say it finds one being used for KillerApp 1.5. All well and good. The next time the user re-installs or updates Killer App 1.5, if it doesn't do the check, it breaks Acme's software. Unfortunately, KillerApp Co take the view of well, our software still works, it must be a problem with Acme. A package designed to do these checks would certainly be a good idea, but it isn't going to happen (be adopted) overnight, and in the meantime, the option of having an isolated cygwin environment is very alluring. So tempting in fact, that I've been considering recompiling with a view to stopping 3rd party apps breaking the sshd which is on our base Win2K3 build. -- AdamT I'm the least you could do. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FAQ suggestion
OK, third draft: Q. I want to bundle Cygwin with a product, and ship it to customer sites. How can I do this without conflicting with any Cygwin installed by the user? A. Third party developers who wish to use Cygwin should check if there is a version of cygwin installed and use the installed version if it is newer, or conditionally upgrade if it is not. (This is same scheme used by Microsoft with great success for its runtime DLLs for many years. If someone wrote a nice utility for doing this type of checking, the Cygwin developers would be happy to put it somewhere on the Cygwin site.) Also, remember that by distributing your project which depends on cygwin, you are bound by the license agreement, http://cygwin.com/licensing.html. Your application must either be under the GPL, or you must purchase a support contract through Red Hat; and if you choose to distribute cygwin1.dll, you must also ensure that you provide the cygwin source code that matches what you distribute. Q. Can I install a private version of cygwin that doesn't conflict with the system cygwin (in the same way that multiple versions of Wine can coexist)? A. The Cygwin maintainers will resist any suggestion to support this, no matter how sensible it might sound to you. Q. But doesn't that mean that if some application installs an older Cygwin library, my application will break? A. Yes. Tough. Don't install applications like that. Q. Doesn't this mean that Cygwin is fragile? A. No. Cygwin is *right*. It's those other applications, or perhaps the users, or both, that are wrong. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: compiling C w/cygwin vs. -mno-cygwin dealing with win32
Brian Dessent wrote:
So cygwin pays attention, and my re-passing the args via execv
preserves the quoting of filenames, but the no-cyg version appears
to take the argv[1..#] arguments and merge them into 1 argument.
To do the same in the no-cyg version, I'd have to peel each arg
off, put quotes around it, then call execv with everything requoted.
Or just link your MinGW version with the MinGW -lexecwrap library.
---
This is part of my prob. I thought the mingw libraries were
automatically selected in place of cygwin libs, I wasn't aware
that the mswin libs had 'execv' (and, really, they sorta don't -- at
least not with the argument-grouping-preserving feature I was
expecting). Uh oh I don't seem to see an execwrap lib on
my system -- and it does not appear to be in the mingw libs
available w/cygwin.*sigh*...sorry, didn't know such a
separate library (or libraries) were available with mingw.
I don't see a list of libraries referenced on the main mingw site..
So you are saying that when I call execv in cygwin, it...
Not quite. What Cygwin does depends on whether it's exec()ing a Cygwin
binary or a non-Cygwin binary.
---
Ah Ha! (*4-watt nightlight bulb turns on in head*). I
wasn't aware that it examined the binaries before executing them.
No wonder process creates in cygwin are a bit slower than one might
'guess'...this explains a fair bit right there.
#include windows.h
#include stdio.h
int WINAPI
WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int nShow)
{
puts (Hello world.);
return 0;
}
---
Ug...that's vaguely familiar...Ug. Now I remember why I
didn't like Windows programming...it's own special API and
notation...all that hungarian notation...sigh. But thanks for
the uncomfortable refresher (I really did force myself to take
a class on Win32 programming at one point, but it was probably
10 years ago, and I never made use of it...so...either the pointer
to it were lost on the stack, or just bit-rotted -- the content might
even have been recycled by garbage collection ...no...not windows
programming information; never that...*cough*).
You can compile this both with Cygwin and MinGW and it will work fine.
Note that the parameters passed to the program are nothing like the C
argc/argv. lpCmd is a pointer to a null terminated string containing
the command line, there is no array of arguments anywhere.
---
Yeah...I remember that [vaguely] from MS-DOS programming days
writing in PL/M and assembler. C was more 'comfortable' when it came
out for DOS...
It's execv that's falling down, not doing it's job. My arguments
are already parsed and separated, but the no-cyg version of execv
is mushing them all back together, while cygwin invokes the
next program, apparently with quotes of some sort, around the
contents of each, separate, argv[] string.
It would not be the first time that someone found MSVCRT less than
adequate. Again, the MinGW project has a convenient set of wrappers for
just this reason.
Isn't MSVCRT the startup code?
No, it's just the opposite: it is the C library minus the startup code.
---
Wrong anacronym. Was thinking about crt0.xxx on *nix systems.
MSVCRT: Visual C Runtime probably...
And whose implementation of execv() do you think that is exactly? It's
not Cygwin's. It's not MinGW's.
---
A confusion on my part. I'm confusing -mno-cygwin with
mingw, sorta -- i.e. I thought it automatically pulled in mingw
libs which in a few cases, I thought, were wrapper functions for
windows functions, and in other cases, just the proper header files
to pull things in from MS's DLL's. I think I'm missing the mingw
library part, sorry for my 'illusionment' (or misillusionment) (versus
being disillusioned completely on being confronted with reality, but
that an allusion to another topic).
No, that's what I've been trying to say the whole time -- MS's exec()
doesn't do any quoting.
---
Got it -- MS never does anything compatible if they can help
it -- should have known it was part of their 'Embrace', 'extend',
'extinguish'...appear to embrace standard *nix C calls, extend them
by helpfully ignoring the separation that was 'encoded' into the
argv vector so you can have one homogeneous command line, and then
extinguish it's use on MS, because it's broken...got it (I too often
forget about the machevellian machinations that various entities
go through to enforce their particular agenda).
Since I'm not forking -- I'm exec'ing, the redirector should
cease to exist (exit), but under cygwin, it does not. That seems more
of a bug in the cygwin implementation, no?
Sigh. No. Aargh!
The *whole* *point* of making the wrapper a MinGW app is so that it will
exit and the the thing its wrapping will appear to run in the
background. This is because the defintion of exec() for a native
program is spawn+exit. The waiting parent will see that the child has
terminated
Re: FAQ suggestion
Adam Thompson wrote: On 18/03/2008, Christopher Faylor wrote: So, we DON'T WANT people doing this. What we actually want a 3PP to do is check if there is a version of cygwin installed and use the installed version if it is a newer or conditionally upgrade if it is not. The problem with this is that it requires the immediate and total cooperation of all 3PPs. Sure - Acme Software might change their application to check for a pre-existing instance of Cygwin, and let's say it finds one being used for KillerApp 1.5. All well and good. The next time the user re-installs or updates Killer App 1.5, if it doesn't do the check, it breaks Acme's software. Unfortunately, KillerApp Co take the view of well, our software still works, it must be a problem with Acme. A package designed to do these checks would certainly be a good idea, but it isn't going to happen (be adopted) overnight, and in the meantime, the option of having an isolated cygwin environment is very alluring. So tempting in fact, that I've been considering recompiling with a view to stopping 3rd party apps breaking the sshd which is on our base Win2K3 build. I feel like I'm caught in a temporal causality loop... -- 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? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FAQ suggestion
On Tue, Mar 18, 2008 at 05:37:09PM -0700, Dan Kegel wrote: OK, third draft: Q. I want to bundle Cygwin with a product, and ship it to customer sites. How can I do this without conflicting with any Cygwin installed by the user? A. Third party developers who wish to use Cygwin should check if there is a version of cygwin installed and use the installed version if it is newer, or conditionally upgrade if it is not. (This is same scheme used by Microsoft with great success for its runtime DLLs for many years. If someone wrote a nice utility for doing this type of checking, the Cygwin developers would be happy to put it somewhere on the Cygwin site.) Also, remember that by distributing your project which depends on cygwin, you are bound by the license agreement, http://cygwin.com/licensing.html. Your application must either be under the GPL, or you must purchase a support contract through Red Hat; and if you choose to distribute cygwin1.dll, you must also ensure that you provide the cygwin source code that matches what you distribute. Q. Can I install a private version of cygwin that doesn't conflict with the system cygwin (in the same way that multiple versions of Wine can coexist)? A. The Cygwin maintainers will resist any suggestion to support this, no matter how sensible it might sound to you. Q. But doesn't that mean that if some application installs an older Cygwin library, my application will break? A. Yes. Tough. Don't install applications like that. Q. Doesn't this mean that Cygwin is fragile? A. No. Cygwin is *right*. It's those other applications, or perhaps the users, or both, that are wrong. Q. I'm an aspiring entrepreneur who wants to take a bunch of your binaries, recompile them with -O3 for speed! and sell them to make some $$$. I've noticed that when my users install my version of super ssh (now with full color support!) along with my copy of cygwin1.dll (version 25.1.7) it conflicts with already installed versions of cygwin1.dll. Please fix this as it affects my bottom line. A. What were we thinking? How could we have been so stupid? We thought we were contributing our time and effort to the Cygwin Project but here we were insensitively ignoring all of those people who just wanted to suck down the binaries and sources that we make available and use them in a manner that they deem convenient. One of our tech support staff will be contacting you shortly to gather details of your exact specifications. Q. I found that by adding one to a magic number in the cygwin sources (which I've managed to figure out how to compile *myself*, please applaud) I can run two versions of cygwin1.dll *at* *the* *same* *time*. You are obviously evil and keeping this simple technique hidden just to piss people off. A. Hey. That wasn't a question. But, yes, you found us out. That's the only thing you have to do. Change one magic number. Q. Hey. I just found out that sometimes when I start bash and run a program I linked against my NEW version of cygwin (which I built *myself*, I know you must be impressed) it segvs or the arguments look funny. I found *another* magic number. You people are truly deranged and evil. A. Once again, not a question. But, you're right. You've found the last thing that you need to change. Q. Now wait a minute. I want my own mount table. Why are you making this so difficult? What earthly reason can you have for not making the mount table configurable so that I can choose whatever registry key I want? I had to change another location in the DLL. A. At last some embedded questions. But, yes, we must be slipping. We forgot that the mount table would give you issues too. Q. When I start up rxvt and run one of the programs that I built against my own version of cygwin (which my friend showed me how to link despite the fact that there are no instructions), my program doesn't work quite right. When it reads from the terminal it doesn't recognize that it's getting input from a tty. The output gets garbled sometimes or there is no output until the program exits. Could you please fix this? A. Just a minute. *pause* Ok. It's fixed. Q. Now what are you trying to pull? I tried to build a version of bash against my new, improved version of cygwin (now with full color support) and it is truncating the command line when I try to run one of your stupid, slow, standard cygwin binaries. Are you hacking my computer to cause me problems? A. It has cmoe to our attenton that your account has been comprimised. Please go to http://cygwin.com/myaccount/ immediately and enter your social security number, bank routing number, and your mother's maidin name if you want to keep receiving future versions of CygWIN. Hurry now, CygWIN now has full color support! You don't want to miss this new versoin! cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation:
Re: FAQ suggestion
On Tue, Mar 18, 2008 at 11:30:43PM -0400, Larry Hall (Cygwin) wrote: Adam Thompson wrote: On 18/03/2008, Christopher Faylor wrote: So, we DON'T WANT people doing this. What we actually want a 3PP to do is check if there is a version of cygwin installed and use the installed version if it is a newer or conditionally upgrade if it is not. The problem with this is that it requires the immediate and total cooperation of all 3PPs. Sure - Acme Software might change their application to check for a pre-existing instance of Cygwin, and let's say it finds one being used for KillerApp 1.5. All well and good. The next time the user re-installs or updates Killer App 1.5, if it doesn't do the check, it breaks Acme's software. Unfortunately, KillerApp Co take the view of well, our software still works, it must be a problem with Acme. A package designed to do these checks would certainly be a good idea, but it isn't going to happen (be adopted) overnight, and in the meantime, the option of having an isolated cygwin environment is very alluring. So tempting in fact, that I've been considering recompiling with a view to stopping 3rd party apps breaking the sshd which is on our base Win2K3 build. I feel like I'm caught in a temporal causality loop... .egnarts fo tros leef I .etunim a tiaW !oot em ,yeH fgc -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gmp/mpfr status
On 3/18/08, Brian Dessent [EMAIL PROTECTED] wrote: Bobby McNulty wrote: It built fine. Installed. Got to build mpfr 2.31, and gmp 4.2.2 kept showing 4.2.1. That's because toplevel configure will find the system gmp header in /usr/include unless you pass --with-gmp=prefix you built gmp with and --with-mpfr=prefix you built mpfr with. He said he installed it. Wouldn't that overwrite the gmp.h that's in /usr/include? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FAQ suggestion
:-) Seriously, though, something belongs in the FAQ about this stuff, doesn't it?My third draft was only one quarter satire; most of it was pretty straight up. I can redraft it without the satire if you like. Don't assume that everyone who asks the question is trying to cheat or bend the rules; I'm a pretty fierce free software advocate myself. I suppose you can just ignore the question, since it only comes up once a year or two. Is that how you'd prefer to handle it? BTW, happy day for us crazy folk: Cygwin runs well enough in Wine that it's starting to feel stable. I'm starting to file bugs against Wine for the remaining issues. Why anybody would want to run Cygwin under Wine I couldn't tell you, but it makes a spiffy test suite for Wine, and is kind of fun. - Dan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FAQ suggestion
On Tue, Mar 18, 2008 at 09:14:21PM -0700, Dan Kegel wrote: :-) Seriously, though, something belongs in the FAQ about this stuff, doesn't it?My third draft was only one quarter satire; most of it was pretty straight up. I can redraft it without the satire if you like. Don't assume that everyone who asks the question is trying to cheat or bend the rules; I'm a pretty fierce free software advocate myself. I assume that they are either trying to 1) cheat, 2) bend the rules, 3) not spend any time whatsoever worrying about the problem, or 4) become annoyed because they have thought about it for thirty seconds and it seems like we're purposely trying to punish them. But, yes, sure, a FAQ entry would not be a bad idea. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FAQ suggestion
Christopher Faylor wrote: I assume that they are either trying to 1) cheat, 2) bend the rules, 3) not spend any time whatsoever worrying about the problem, or 4) become annoyed because they have thought about it for thirty seconds and it seems like we're purposely trying to punish them. I have to think the question comes up frequently, else it wouldn't elicit such a strong reaction. But, yes, sure, a FAQ entry would not be a bad idea. OK, I'm game: --- snip --- 9. Deploying Cygwin 9.1 I want to bundle Cygwin with a product, and ship it to customer sites. How can I do this without conflicting with any Cygwin installed by the user? A. Third party developers who wish to use Cygwin should check if there is a version of cygwin installed and use the installed version if it is newer, or conditionally upgrade if it is not. (If you write a tool to make this easy, consider contributing it to cygwin for others to use.) 9.2 Can I bundle Cygwin with my product for free? A. Only if you comply with Cygwin's license very carefully. If you choose to distribute cygwin1.dll, you must also distribute the exact source code used to build that copy of cygwin1.dll. If you ship applications that link with cygwin1.dll, you must either provide those applications' source code under a GPL-compatible license, *or* purchase a cygwin license from Red Hat. 9.3. Can I install a private version of cygwin that doesn't conflict with the system cygwin (in the same way that multiple versions of Wine can coexist)? A. The Cygwin maintainers will resist any suggestion to support this, no matter how sensible it might sound to you, because they feel strongly that the only supportable situation is for everybody to use the same cygwin instance, and for it to be as up to date as possible. 9.4. But doesn't that mean that if some application installs an older Cygwin library than my system had, my application will break? A. Yes. If you run into such an application, uninstall it, point the author to this FAQ, and try to get them to follow the cygwin deployment rules. --- snip --- Is that getting closer? - Dan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gmp/mpfr status
Bobby McNulty wrote: It built fine. Installed. Got to build mpfr 2.31, and gmp 4.2.2 kept showing 4.2.1. That's because toplevel configure will find the system gmp header in /usr/include unless you pass --with-gmp=prefix you built gmp with and --with-mpfr=prefix you built mpfr with. He said he installed it. Wouldn't that overwrite the gmp.h that's in /usr/include? -- That was where i installed it to. /usr my prefix was --prefix=/usr nothing else -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: FAQ suggestion
From: Dan Kegel Christopher Faylor wrote: I assume that they are either trying to 1) cheat, 2) bend the rules, 3) not spend any time whatsoever worrying about the problem, or 4) become annoyed because they have thought about it for thirty seconds and it seems like we're purposely trying to punish them. I have to think the question comes up frequently, else it wouldn't elicit such a strong reaction. But, yes, sure, a FAQ entry would not be a bad idea. OK, I'm game: [snip] Allow me to be the first to thank you, Dan, for contributing to the Cygwin documentation (or attempting to at any rate). While I of course cannot speak for anyone else, I am sure that all other professionals here appreciate your efforts. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Updated: cygrunsrv-1.34-1
I have updated cygrunsrv to version 1.34-1. This release mainly improves the capability to connect to remote servers introduced with 1.30-1 (see http://cygwin.com/ml/cygwin-announce/2008-03/msg00052.html) The following changes have been made: - When accessing a remote server, cygrunsrv no longer checks the path to the executable for existance, nor does it check if the registry contains required system mount points. - There's a new option -P/--crs-path which allows to specify the path to cygrunsrv. This is especially useful when installing services on a remote machine and the path to cygrunsrv is evaluated incorrectly to run the service correctly on the remote machine. - Erroneous error output when registry access fails has been fixed. - It's now allowed to specify NT user names in the DOMAIN\username syntax also using a forward slash, DOMAIN/username. - A couple of ambiguities in the README file /usr/share/doc/Cygwin/cygrunsrv.README have been fixed. If you have questions or comments, please send them to the Cygwin mailing list at: [EMAIL PROTECTED] . I would appreciate if you would use this mailing list rather than emailing me directly. This includes ideas and comments about the setup utility or Cygwin in general. If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe to 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: [EMAIL PROTECTED] -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
