[ITA/P] DocBook
I believe that my DocBook stack is now ready for the distro: http://mirrors.kernel.org/sources.redhat.com/cygwinports/release-2/DocBook/ http://mirrors.kernel.org/sources.redhat.com/cygwinports/release-2/Perl/perl-SGMLSpm/ New: build-docbook-catalog dblatex docbook-dsssl docbook-sgml30 docbook-sgml31 docbook-sgml40 docbook-sgml41 docbook-sgml42 docbook-sgml43 docbook-sgml44 docbook-sgml45 docbook-utils docbook-xml-simple10 docbook-xml-simple11 docbook-xml45 jadetex perl-SGMLSpm sgml-common Adopted: docbook-xml412 docbook-xml42 docbook-xml43 docbook-xml44 docbook-xsl openjade (libostyle1, libostyle-devel) OpenSP (libosp5, libosp-devel) The stack uses Gentoo's layout, installing all DTDs (both SGML and XML) under /usr/share/sgml/docbook/, and their own build-docbook-catalog script for managing the XML catalog registration. SGML catalog registration is managed by sgml-common, which is used by several distros. All DTD catalog registration is managed with postinstall/preremove scripts. docbook-utils is the top of the stack, and includes jw(1) and the docbook2* commands for SGML and XML. It depends on ALL these components and a few more already maintained in the distro, so simply installing docbook-utils should pull in everything you need to use docbook2*. I have tested these packages against cygwin-doc, cygwin-x-doc, fontconfig, and xorg-docs, which all use these new tools extensively. Yaakov
Re: [ITP] ucspi-tcp
On Jan 31 21:18, Steven Monai wrote: I have created a cygport script to package D. J. Bernstein's 'ucspi-tcp' software. I propose to submit the package for inclusion in the Cygwin package archive, with myself as its maintainer. [...] As per http://cygwin.com/setup.html#submitting , here is the text of the 'setup.hint' file: category: Net requires: cygwin libgcc1 sdesc: Command-line tools for building TCP client-server applications ldesc: Command-line tools for building TCP client-server applications ucspi-tcp is in Debian GNU/Linux. Here is a link to the sid binary package page: http://packages.debian.org/sid/ucspi-tcp If there is any interest, I can make my cygport script and source patches available for http download from a publically accessible server. There's certainly interest. You just missed out on http://cygwin.com/setup.html#submitting, point 5. Please send the URLs to your binary and source packages, otherwise it's a bit tricky to review them. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
YA gold star (was Re: [ITA/P] DocBook)
On Feb 1 02:38, Yaakov S wrote: I believe that my DocBook stack is now ready for the distro: Yes, please! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] plotutils
Marco Atzeri wrote: as Corinna said, we are starting a PACman action. The packages are cygwinport ones, courtesy of Yaakov. Just a version bump. plotutils-devel and plotutils-doc are obsoleted the development packages are 3 libplot-devel libplotter-devel libxmi-devel one for each of the dll's libxmi0usr/bin/cygxmi-0.dll libplot2 usr/bin/cygplot-2.dll libplotter2usr/bin/cygplotter-2.dll to download: Rebuilds fine from src. GTG. Auto gold star awarded. http://cygwin.com/goldstars/#MA
Re: YA gold star (was Re: [ITA/P] DocBook)
On Feb 1 02:38, Yaakov S wrote: I believe that my DocBook stack is now ready for the distro: Yes, please! Gold star awarded. http://cygwin.com/goldstars/#YS
Re: YA gold star (was Re: [ITA/P] DocBook)
On 01/02/2010 03:18, Corinna Vinschen wrote: Yes, please! Uploaded, announced, and updated cygwin-pkg-maint accordingly. Yaakov
Re: [ITP] ucspi-tcp
On 2010/02/01 1:13 AM, Corinna Vinschen wrote: There's certainly interest. You just missed out on http://cygwin.com/setup.html#submitting, point 5. Please send the URLs to your binary and source packages, otherwise it's a bit tricky to review them. Sorry, I was a bit confused about when to provide the URLs. Well anyway, here they are: http://dev.monai.ca/cygwin/itp/ucspi-tcp/setup.hint http://dev.monai.ca/cygwin/itp/ucspi-tcp/ucspi-tcp-0.88-1-src.tar.bz2 http://dev.monai.ca/cygwin/itp/ucspi-tcp/ucspi-tcp-0.88-1.tar.bz2 All the above files can be downloaded with a single command: wget -r -nd -np http://dev.monai.ca/cygwin/itp/ucspi-tcp/ Thanks, -SM --
Problems with tcsh on startup of cygwin X
Each time I start up cygwin-X I get these error messages in the Xterm window that lingers after the Xterm windows opens. This is frustrating because it just make it that much harder to use cygwin on Windows 7. Clogs up the task bar with processes that you can't use. Anyway, any ideas on why tcsh is failing. 2 [main] tcsh 976 C:\Xwin\bin\tcsh.exe: *** fatal error - couldn't allocate heap, Win32 error 487, base 0x7A, top 0x87E000, reserve_size 905216, allocsize 909312, page_const 4096 1 [main] -tcsh 3276 child_info::sync: wait failed, pid 976, Win32 error 1812 327 [main] -tcsh 3276 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0x100, errno 11 1 [main] tcsh 3232 C:\Xwin\bin\tcsh.exe: *** fatal error - couldn't allocate heap, Win32 error 487, base 0x7A, top 0x87E000, reserve_size 905216, allocsize 909312, page_const 4096 310590390 [main] -tcsh 3276 child_info::sync: wait failed, pid 3232, Win32 error 1812 310591317 [main] -tcsh 3276 fork: child -1 - died waiting for longjmp before ini tialization, retry 0, exit code 0x100, errno 11 Also, the last Xterm that I started from the start menu hung with this error: No more processes. thanks, jerry -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/doc ChangeLog faq-programming.xml
CVSROOT:/cvs/src Module name:src Changes by: yselkow...@sourceware.org 2010-02-01 19:18:03 Modified files: winsup/doc : ChangeLog faq-programming.xml Log message: * faq-programming.xml: Update for Cygwin docbook-utils package. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/doc/ChangeLog.diff?cvsroot=srcr1=1.267r2=1.268 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/doc/faq-programming.xml.diff?cvsroot=srcr1=1.14r2=1.15
src/winsup/cygwin ChangeLog how-startup-shutdo ...
CVSROOT:/cvs/src Module name:src Changes by: da...@sourceware.org2010-02-02 01:54:56 Modified files: winsup/cygwin : ChangeLog Added files: winsup/cygwin : how-startup-shutdown-works.txt Log message: * how-startup-shutdown-works.txt: Add new document. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/how-startup-shutdown-works.txt.diff?cvsroot=srcr1=NONEr2=1.1 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4791r2=1.4792
winsup/cygwin ChangeLog dcrt0.cc dll_init.cc d ...
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2010-02-02 02:00:02 Modified files: cygwin : ChangeLog dcrt0.cc dll_init.cc dll_init.h init.cc Log message: * dcrt0.cc (atexit_lock): Delete. (cygwin_exit): Remove atexit lock. (cygwin_atexit): Ditto. Rename parameter to match newlib. Call __cxa_atexit when invoked by a registered DLL. * dll_init.cc (remove_dll_atexit): Delete. (dll_list::find): New function. (dll_list::detach): Use dll_list::find to find dll associated with return address. Use __cxa_finalize to run atexit functions associated with the dll. (cygwin_detach_dll): Don't assume that HANDLE == void *. * dll_init.h (dll_list::find): Declare. (__cxa_atexit): Ditto. (__cxa_finalize): Ditto. * init.cc (dll_entry): Clarify comment. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.4792r2=1.4793 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/dcrt0.cc.diff?cvsroot=uberbaumr1=1.370r2=1.371 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/dll_init.cc.diff?cvsroot=uberbaumr1=1.68r2=1.69 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/dll_init.h.diff?cvsroot=uberbaumr1=1.18r2=1.19 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/init.cc.diff?cvsroot=uberbaumr1=1.77r2=1.78
[PATCH] winsup/doc/README: docbook-utils
This patch updates winsup/doc/README for the new docbook-utils package, which provides the docbook2pdf command for building the PDFs. As for the note about docbook2X (which is a separate package not included in today's additions) for info pages, I missed that until now because it is not part of the Makefile. If someone could give me some details on what has been done until now, I'll see what I can do about that as well. Yaakov 2010-Feb-01 Yaakov Selkowitz yselkow...@cygwin.com * README: Update for Cygwin docbook-utils package. Index: README === RCS file: /cvs/src/src/winsup/doc/README,v retrieving revision 1.1 diff -u -r1.1 README --- README 24 Feb 2005 05:26:33 - 1.1 +++ README 1 Feb 2010 20:43:57 - @@ -3,10 +3,11 @@ BUILD REQUIREMENTS: -ash +bash bzip2 coreutils cygwin +docbook-utils docbook-xml42 docbook-xsl gzip @@ -20,9 +21,7 @@ You may use docbook2X to convert the DocBook files into info pages. I have not been able to get a working docbook2X installation on Cygwin, -so currently I convert the files on a machine running GNU/Linux. PDF -generation is also problematic; I use 'jw -b pdf' right now but have -also used 'xmlto pdf' and jade. +so currently I convert the files on a machine running GNU/Linux. A few handmade files (cygwin.texi, intro.3, etc.) are found in the cygwin-doc-x.y-z-src.tar.bz2 package. It also contains the utilities for
Re: dlclose not calling destructors of static variables.
On Mon, Feb 01, 2010 at 08:17:05PM +, Dave Korn wrote: On 01/02/2010 19:28, Dave Korn wrote: On 01/02/2010 17:51, Christopher Faylor wrote: On Mon, Feb 01, 2010 at 12:46:11PM -0500, Christopher Faylor wrote: Cribbing from the gdb source code, it looks like they use BaseAddrees + 0x1000 for the start point and then call GetModuleInformation to workout the size of the module. Yeah, duh. they == me. I should have checked gdb for this since I've already done this research once before. If you do find that this works, then I think this may fall into the realm of a non-trivial patch so it may be best to just tell me what you've found rather than provide a patch - unless you want to go through the approval process with Red Hat. Or, you can just wait for me to adapt what's in gdb to cygwin. I can do tonight when I get back to a windows system. Btw, it isn't entirely clear that GetModuleInformation will work with older versions of Windows NT so this may not be a complete solution. We do use GetModuleInformation in Cygwin but it is not in anything as crucial as this. Can't we use the info in the dll struct? It has pointers to the data and bss section, we could take the max out of them and the data in the M_B_I struct. (Tell you what, I'll try it.) Yep, that makes the original testcase work for me. How about it? Since the testcase (obviously?) worked for me it seems like this is pretty variable. I'd like to understand why the MEMORY_BASIC_INFORMATION method doesn't work before trying other things. cgf
Re: dlclose not calling destructors of static variables.
On 01/02/2010 21:59, Christopher Faylor wrote: Since the testcase (obviously?) worked for me it seems like this is pretty variable. I'd like to understand why the MEMORY_BASIC_INFORMATION method doesn't work before trying other things. Hmm, well first off, looks like RegionSize is indeed relative to BaseAddress, not AllocationBase after all: http://msdn.microsoft.com/en-us/library/aa366775(VS.85).aspx RegionSize The size of the region beginning at the base address in which all pages have identical attributes, in bytes. http://msdn.microsoft.com/en-us/library/aa366902(VS.85).aspx The function returns the attributes and the size of the region of pages with matching attributes, in bytes. For example, if there is a 40 megabyte (MB) region of free memory, and VirtualQuery is called on a page that is 10 MB into the region, the function will obtain a state of MEM_FREE and a size of 30 MB. cheers, DaveK
Re: dlclose not calling destructors of static variables.
On 01/02/2010 22:36, Dave Korn wrote:
On 01/02/2010 21:59, Christopher Faylor wrote:
Since the testcase (obviously?) worked for me it seems like this is pretty
variable. I'd like to understand why the MEMORY_BASIC_INFORMATION method
doesn't work before trying other things.
Hmm, well first off, looks like RegionSize is indeed relative to
BaseAddress, not AllocationBase after all:
This is what I'm going to test next. It avoids calling anything registered
with the cxa functions, i.e. only calls ordinary atexit hooks, and it handles
the case where extra atexit blocks have been chained on the end.
cheers,
DaveK
Index: dll_init.cc
===
RCS file: /cvs/src/src/winsup/cygwin/dll_init.cc,v
retrieving revision 1.68
diff -p -u -r1.68 dll_init.cc
--- dll_init.cc 29 Jan 2010 18:34:09 - 1.68
+++ dll_init.cc 1 Feb 2010 23:01:08 -
@@ -153,19 +153,27 @@ dll_list::alloc (HINSTANCE h, per_proces
register an atexit function outside of the DLL and that should be
run when the DLL detachs. */
static void
-remove_dll_atexit (MEMORY_BASIC_INFORMATION m)
+remove_dll_atexit (const MEMORY_BASIC_INFORMATION m)
{
- unsigned char *dll_beg = (unsigned char *) m.AllocationBase;
- unsigned char *dll_end = (unsigned char *) m.AllocationBase + m.RegionSize;
+ unsigned char *dll_beg = (unsigned char *) m.BaseAddress;
+ unsigned char *dll_end = (unsigned char *) m.BaseAddress + m.RegionSize;
struct _atexit *p = _GLOBAL_REENT-_atexit;
- for (int n = p-_ind - 1; n = 0; n--)
-{
- void (*fn) (void) = p-_fns[n];
- if ((unsigned char *) fn = dll_beg (unsigned char *) fn dll_end)
+
+ while (p)
+{
+ for (int n = p-_ind - 1; n = 0; n--)
{
- fn ();
- p-_fns[n] = NULL;
- }
+ void (*fn) (void) = p-_fns[n];
+ if ((p-_on_exit_args._is_cxa (1 n)) == 0
+ (unsigned char *) fn = dll_beg (unsigned char *) fn dll_end)
+ {
+ /* Remove the function now to protect against the
+ function calling exit recursively. */
+ p-_fns[n] = NULL;
+ fn ();
+ }
+ }
+ p = p-_next;
}
}
[PATCH] Add some notes about process startup/shutdown.
Here's some notes I've been making; reckon they might come in handy for anyone who wants to untangle some of this stuff in the future. Attached the whole file rather than gratuitously prefixing every line with a '+' to no great effect! :) There'll be another later, to explain how the cxx abi interacts with all this. winsup/cygwin/ChangeLog: * how-crt-and-initfini.txt: Add new document. OK? cheers, DaveK Copyright 2010 Red Hat Inc., contributed by Dave Korn. How the C runtime handles startup and termination. -- This file documents the processes involved in starting up and shutting down a Cygwin executable. The responsibility is divided between code that is statically linked into each Cygwin-based DLL or executable as part of the C runtime, and code in the Cygwin DLL itself that co-operates with it. The runtime library code lives in the winsup/cygwin/lib directory, and a little of it is in winsup/cygwin/include/cygwin/cygwin_dll.h Process overall startup sequence. = Overall process startup (and indeed termination) is under the control of the underlying Windows OS. The details of the Win32 CreateProcess API and the underlying NT Native API ZwCreateProcess calls are far more complex (and unknown, since proprietary) than we need go into here; the important details are that the process address space is first created, then an initial thread is spawned that performs DLL initialisation, calling the DllMain functions of all statically-linked DLLs in load order. This thread is also serialised under the Windows OS global loader lock, and DllMain functions are very limited in what they can do as a consequence; to help deal with this, cygwin wraps the user's DllMain function and defers calling it until runtime. Once the DLLs have been initialised, the initial thread then performs C runtime setup and calls into the executable's main() function. Entry sequence for Cygwin-based DLLs. = In the compiler's LINK_SPEC, a -e option sets the entry point (what Windows regards as DllMain) to __cygwin_dll_en...@12. This is defined in include/cygwin/cygwin_dll.h. The user's DllMain function, if any, is called from within this function - directly in the case of thread attach/detach notifications and process detach, but indirectly at process attach time via cygwin_attach_dll in lib/cygwin_attach_dll.c, which calls the CRT common code _cygwin_crt0_common and then hands off to the Cygwin DLL at dll_dllcrt0. The CRT common code doesn't call the user DllMain at once; it caches a pointer to it in the 'main' member of the DLL's per_process struct. __cygwin_dll_en...@12 - cygwin_attach_dll - (_cygwin_crt0_common) - dll_dllcrt0 - (DllMain?maybe?) dll_dllcrt0 is in dll_init.cc sets up exception handler, ensures cygwin DLL is at least partially initialised, allocates a new entry for the DLL chain, and either calls the 'main' function (via dll::init) before returning to the OS loader, or defers doing so until dll_crt0_1 runs dlls.dll_list::init() during the application's startup sequence, depending on whether Cygwin DLL was fully initialised yet or not. In general statically linked DLLs will defer, while dlopen'd DLLs will run at once. The Cygwin DLL runs the dependent DLL's ctors immediately prior to making the call, whether immediate or deferred. Entry sequence for Cygwin-based executables. The entry point is the windows standard entrypoint, WinMainCRTStartup, aliased to mainCRTStartup, defined in crt0.c. It aligns the stack, sets the x87 fpu cw, and hands off to cygwin_crt0 in lib/cygwin_crt0.c, which calls the CRT common init code in _cygwin_crt0_common and heads off into the DLL, never to return from _dll_crt0. mainCRTStartup - cygwin_crt0 - (_cygwin_crt0_common) - _dll_crt0 - dll_crt0_1 - (n*DllMain?maybe?) - main - (__main) - cygwin_exit This is a wrapper that does some fork-related stack sorting out then hands off to dll_crt0_1, which completes all Cygwin DLL initialisation, runs any deferred DllMain calls, and jumps into the application, returning via the termination routines. Post-entry construction. The compiler automatically inserts a hidden call to __main at the start of the user's main() function. During startup, DLL constructors are run in dll:init() immediately prior to calling that DLL's DllMain function (not in a forkee, though; once is enough). In __main, all statically-loaded DLL ctors are now complete, so we queue an atexit call to dll_global_dtors, then run the application's ctors and queue an atexit call to do_global_dtors. Process overall termination sequence. = The program termination sequence can begin in one of the following ways: - by returning from main() - by calling exit(),
Re: [PATCH] Add some notes about process startup/shutdown.
On Tue, Feb 02, 2010 at 01:23:54AM +, Dave Korn wrote: Here's some notes I've been making; reckon they might come in handy for anyone who wants to untangle some of this stuff in the future. Attached the whole file rather than gratuitously prefixing every line with a '+' to no great effect! :) There'll be another later, to explain how the cxx abi interacts with all this. winsup/cygwin/ChangeLog: * how-crt-and-initfini.txt: Add new document. OK? Yes, very nice except I don't think the name is descriptive enough and in keeping with the other stuff in the series. Maybe how-startup-shutdown-work.txt ? cgf
Re: [PATCH] Add some notes about process startup/shutdown.
On Tue, Feb 02, 2010 at 02:08:17AM +, Dave Korn wrote: On 02/02/2010 01:39, Christopher Faylor wrote: winsup/cygwin/ChangeLog: * how-crt-and-initfini.txt: Add new document. OK? Yes, very nice except I don't think the name is descriptive enough and in keeping with the other stuff in the series. Maybe how-startup-shutdown-work.txt ? Okeydokey, will check it in with that name (well, modulo -works). That wasn't a typo. I actually chose work specifically because I was thinking it was how startup and shutdown work. But nevermind. cgf
Re: Cygwin v.1.7.1/OpenSSH v.5.3: Userswitching by using LSA Authentication does not work: Problem solved!
Hello, Corinna, excuse me (s. above!)! cygwin-ow...@cygwin.com schrieb am 29.01.2010 14:59:24: [Bild entfernt] Re: Cygwin v.1.7.1/OpenSSH v.5.3: Userswitching by using LSA Authentication does not work... Corinna Vinschen an: cygwin 29.01.2010 15:00 Gesendet von: cygwin-ow...@cygwin.com Bitte Antwort an cygwin On Jan 29 13:45, carsten.porz...@spb.de wrote: As a temporary workaround for 64 bit users, I uploaded a cyglsa64.dll for Cygwin 1.7.1: ftp://cygwin.com/pub/cygwin/unsupported/cyglsa64.dll SHA1(cyglsa64.dll)= 1874190ab912bc444b2cc468bb74cb294e6bc35b To replace the running cyglsa64.dll, copy the above DLL to /bin, then: bash$ cd /bin/cyglsa bash$ mv cyglsa64.dll cyglsa64.OLD bash$ cp ../cyglsa64.dll . Reboot. When Cygwin 1.7.2 is released, you will have to do that again, or, alternatively, run cyglsa-config. I'll change cyglsa so that this isn't necessary in future anymore. Thanks a lot for the quick help! It works now! But, it is necessary, that the logon user's primary group is the Adminstrators group (544) within the passwd file. Ohterwise, the logon failed. u!? Not on my machine. My acount has a normal domain account as primary group. It was a false alarm! There was something wrong with my installation. After installation on another machine, everything is OK! Nevertheless, could you care for the problem with the uncomplete output during executing commands directly by using SSH? Or do I have to create a bug report for this (as Larry Hall said in his email of January, 21st)? You solved the problem in Cygwin v.1.7.0 about one and a half year ago. Thanks in advance for a short information about this and best regards Carsten Porzler Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin v.1.7.1/OpenSSH v.5.3: Userswitching by using LSA Authentication does not work: Problem solved!
On Feb 1 10:41, carsten.porz...@spb.de wrote: cygwin-ow...@cygwin.com schrieb am 29.01.2010 14:59:24: But, it is necessary, that the logon user's primary group is the Adminstrators group (544) within the passwd file. Ohterwise, the logon failed. u!? Not on my machine. My acount has a normal domain account as primary group. It was a false alarm! There was something wrong with my installation. After installation on another machine, everything is OK! Nevertheless, could you care for the problem with the uncomplete output during executing commands directly by using SSH? Or do I have to create a bug report for this (as Larry Hall said in his email of January, 21st)? You solved the problem in Cygwin v.1.7.0 about one and a half year ago. I don't know what you're referring to. Can you please point to the thread in the cygwin ML archive(*)? And, if I fixed it, how come that you're still seeing it? And if it's actually a generic problem, how come that neither Larry nor I can reproduce it? I tried with an ssh client from Cygwin against a non-Cygwin sshd server, against a Windows sshd server using cyglsa, and a Windows sshd server using the passwordless w/ password(**) method. In all three cases I can't see this effect. From my perspective it looks like a local problem on your side. Corinna (*) http://cygwin.com/ml/cygwin/ (**) http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd3 -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: dlclose not calling destructors of static variables.
On 29/01/2010 18:45, Christopher Faylor wrote:
On Fri, Jan 29, 2010 at 02:30:48PM +, Andrew West wrote:
On 29/01/2010 13:08, Dave Korn wrote:
On 28/01/2010 11:21, Andrew West wrote:
I seem to be having a problem with dlclose not calling the destructors
of statically declared variables. I've attached a simple test case
which I compile as follows;
Thanks for the report and the STC; this should work. I'll take a look
at it over the weekend or the start of next week if nobody else gets
there first.
Thanks for looking into this, it looks a little more complex than I
first thought.
I've tried calling __call_exitprocs during dlclose ( after run_dtors
for the unloading library ) just to see if I was thinking along the
right lines. Unfortunately this didn't work as when the destructor is
registered with atexit it isn't associated with the loaded library but
with the main executable.
Which brings me on to the bigger problem, the static variables are
registered with atexit rather than with __cxa_atexit which seems to be
a violation of the C++ standard (1).
Worse still gcc isn't compiled with cxa_atexit enabled. So I assume
the right course of action here is to enable __cxa_atexit in gcc, and
then make sure __cxa_finalize gets called when the library is unloaded?
I agree with your assessment here. I've checked in a change which works
around the problem you've uncovered but it is not foolproof. It should
fix the immediate problem but, in the long run, I agree that gcc should
be emitting code which calls __cxa_atexit. Of course I have no idea
what the other ramifications of doing that might be. Hopefully Dave can
enlighten us.
This is in today's snapshot at http://cygwin.com/snapshots/ .
cgf
Hi,
I checked out the changes and it still crashed for me. Digging into it
the destructor for testlib fell outside of dll_end ( m.AllocationBase +
m.RegionSize ). On a whim I change m.AllocationBase to m.BaseAddress and
that seemed to fix it for me! The destructor ran on dlclose and the
testrunner.exe didn't segfault.
For what it's worth the small change is attached as a patch.
Andy
Index: winsup/cygwin/dll_init.cc
===
RCS file: /cvs/src/src/winsup/cygwin/dll_init.cc,v
retrieving revision 1.68
diff -u -p -r1.68 dll_init.cc
--- winsup/cygwin/dll_init.cc 29 Jan 2010 18:34:09 - 1.68
+++ winsup/cygwin/dll_init.cc 1 Feb 2010 11:43:17 -
@@ -155,8 +155,8 @@ dll_list::alloc (HINSTANCE h, per_proces
static void
remove_dll_atexit (MEMORY_BASIC_INFORMATION m)
{
- unsigned char *dll_beg = (unsigned char *) m.AllocationBase;
- unsigned char *dll_end = (unsigned char *) m.AllocationBase + m.RegionSize;
+ unsigned char *dll_beg = (unsigned char *) m.BaseAddress;
+ unsigned char *dll_end = (unsigned char *) m.BaseAddress + m.RegionSize;
struct _atexit *p = _GLOBAL_REENT-_atexit;
for (int n = p-_ind - 1; n = 0; n--)
{
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bash completion and symlinks problem
Hi all, another problem after updating cgwin . The bash completion don't work for symlinks . assume having a /cygdrive/c/bin directory which contains symlinks to scripts in a central directory on our file sever say /cygdrive/x /centraltools/ eg. /cygdrive/c/bin/dosomething.pl - /cygdrive/x /centraltools/dosomething.pl The strange thing is, old links as well as new ones executed fine. Only they don't appear in the completion. Can someone tell me why ?? Kindly regards Norbert -- Dipl. Phys. Norbert Zacharias Wind Measurements Power Curve Measurements DEWI GmbH Ebertstrasse 96 26382 Wilhelmshaven Germany Tel.: +49 4421 4808 876 Fax:+49 4421 4808 843 Email: n.zachar...@dewi.de Home: http://http://www.dewi.de DEWI GmbH - Deutsches Windenergie-Institut, Wilhelmshaven Commercial Register No.: Amtsgericht Oldenburg, HRB 130241 Managing Director: Jens Peter Molly Chairman of the supervisory board: Ministerialrat Dr. Niels Kämpny P Please consider the environment before printing this email. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
./configure on cygwin in window platform
Please help me out. I spent for three days but I still could install gcc in window on cygwin. Problem is I could not install gcc file, (mingw-w64-trunk-snapshot-20091222.tar.bz2), on cygwin in window platform. I would like to unpack and intall gcc (mingw-w64-trunk-snapshot-20091222.tar.bz2) on cygwin on window platform. I follow instruction posted on http://cygwin.wikia.com/wiki/How_to_install_GCC_4.3.0. The problem I have found out is I could not process the configure step as below. The result shows No such file or directory Steps: $ mkdir build $ cd build $ ../gcc-*/configure --enable-languages=c,c++ $ make $ make install May it be because of (1) setting srcdir or objdir non-correctly or (2) else ? What I have done are: 1. Download gcc file and load it into /usr/build. Build subfolder is created by me. -- ( equal to $ mkdir build and $ cd build) 2. Unpack gcc tar.bz2 file (mingw-w64-trunk-snapshot-20091222.tar.bz2) on that location. -- It generates trunk subfolder that contains some subfolder too. 3. $mkdir build and $cd build -- current location is urs/build 4. $ ../trunk/configure --enable-languages=c,c++ -- It does not work. Error = No such file or directory Comparing to what you recommend on http://gcc.gnu.org/install/configure.html , To configure GCC: % mkdir objdir % cd objdir % srcdir/configure [options] [target] You mentions that objdir can not be a subdirectory of srcdir. This is why I tried one more time with the different folder and the same level under usr folder. What I did are: 1. Download gcc (mingw-w64-trunk-snapshot-20091222.tar.bz2) for window platform again into usr/tmp 2. Unpack it in the usr/tmp/. The path result are approximately usr/tmp/trunk/mingw..1* usr/tmp/trunk/mingw..2* usr/tmp/trunk/mingw..3* usr/tmp/trunk/mingw..4* 3. $cd build -- under usr folder -- current location is usr/build -- build is already created by me on the previous work. 4 command to configure - $../mingw-w64-trunk-snapshot-20091222.tar.bz2/configure --enable-language=c,c++ -- Show error msg = No such file or directory 5. Try $ ../trunk/mingw-w64-trunk-snapshot-20091222.tar.bz2/configure --enable-language=c,c++ -- Show error msg = No such file or directory. Please help me out. I don't why I could not and thank you very much, Jasmine Ps. I am pretty much new with cygwin and this is my first time. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ./configure on cygwin in window platform
Please help me out. I spent for three days but I still could install gcc in window on cygwin. Problem is I could not install gcc file, (mingw-w64-trunk-snapshot-20091222.tar.bz2), on cygwin in window platform. I would like to unpack and intall gcc (mingw-w64-trunk-snapshot-20091222.tar.bz2) on cygwin on window platform. I follow instruction posted on http://cygwin.wikia.com/wiki/How_to_install_GCC_4.3.0. The problem I have found out is I could not process the configure step as below. The result shows No such file or directory Steps: $ mkdir build $ cd build $ ../gcc-*/configure --enable-languages=c,c++ $ make $ make install May it be because of (1) setting srcdir or objdir non-correctly or (2) else ? What I have done are: 1. Download gcc file and load it into /usr/build. Build subfolder is created by me. -- ( equal to $ mkdir build and $ cd build) 2. Unpack gcc tar.bz2 file (mingw-w64-trunk-snapshot-20091222.tar.bz2) on that location. -- It generates trunk subfolder that contains some subfolder too. 3. $mkdir build and $cd build -- current location is urs/build 4. $ ../trunk/configure --enable-languages=c,c++ -- It does not work. Error = No such file or directory Comparing to what you recommend on http://gcc.gnu.org/install/configure.html , To configure GCC: % mkdir objdir % cd objdir % srcdir/configure [options] [target] You mentions that objdir can not be a subdirectory of srcdir. This is why I tried one more time with the different folder and the same level under usr folder. What I did are: 1. Download gcc (mingw-w64-trunk-snapshot-20091222.tar.bz2) for window platform again into usr/tmp 2. Unpack it in the usr/tmp/. The path result are approximately usr/tmp/trunk/mingw..1* usr/tmp/trunk/mingw..2* usr/tmp/trunk/mingw..3* usr/tmp/trunk/mingw..4* 3. $cd build -- under usr folder -- current location is usr/build -- build is already created by me on the previous work. 4 command to configure - $../mingw-w64-trunk-snapshot-20091222.tar.bz2/configure --enable-language=c,c++ -- Show error msg = No such file or directory 5. Try $ ../trunk/mingw-w64-trunk-snapshot-20091222.tar.bz2/configure --enable-language=c,c++ -- Show error msg = No such file or directory. Please help me out. I don't why I could not and thank you very much, Jasmine Ps. I am pretty much new with cygwin and this is my first time. Hello Jasmine, I can see that you are using mingw-w64 sources and you should first asked on irc.oftc.net (http://mingw-w64.sourceforge.net/mibbit.html) how to do it because there is always someone that can help you. I recommend also to read this : http://sourceforge.net/apps/trac/mingw-w64/wiki/Cross%20Win32%20and%20Win64%20compiler Generally mingw-w64 provides also some script to compile their toolchain, at least last time I tried there was a script that you could use as an install guide. Compiling mingw-w64 is a bit specific because if you try to compile gcc-4.5 there are some details like multilib and you should read their FAQ. Hope this helps a bit. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Putting a cygwin installation under bzr VCS ?
So, what do you think about putting one standard installation under bzr (Windows) control and then pulling in changes from the different PC's when they are ready for it ? That seems like a workable approach. A disadvantage is that by putting all of those binaries into bzr, you'd get a large .bzr directory, with all of the previous versions of every binary. However, that would only be true on the master host. On the slave hosts you could use lightweight checkouts and so not take up all of the extra space there for history. A lighter-weight approach would be to use rsync or unison instead, to synchronize the satellite hosts to the master. That would avoid the space and work overhead of keeping the version control history, but you'd lose the ability to roll back changes if for some reason they created problems. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: dlclose not calling destructors of static variables.
On 01/02/2010 11:46, Andrew West wrote: I checked out the changes and it still crashed for me. Digging into it the destructor for testlib fell outside of dll_end ( m.AllocationBase + m.RegionSize ). On a whim I change m.AllocationBase to m.BaseAddress and that seemed to fix it for me! The destructor ran on dlclose and the testrunner.exe didn't segfault. As promised, I'm working on the other half of this problem. On 29/01/2010 18:45, Christopher Faylor wrote: I agree with your assessment here. I've checked in a change which works around the problem you've uncovered but it is not foolproof. It's definitely the right thing to do, we'll need it for a while to support any existing DLLs with ctors. (We did touch on this whole area briefly back when sorting out the mallocwrapper stuff w.r.t dlopen/close, and I looked at it briefly then but we were trying to stabilise for 1.7.1 at the time.) Doesn't remove_dll_atexit() need some locking, though? It should fix the immediate problem but, in the long run, I agree that gcc should be emitting code which calls __cxa_atexit. Of course I have no idea what the other ramifications of doing that might be. Hopefully Dave can enlighten us. I'm doing a patch this afternoon to add the necessary support in the DLL and CRT. Once that's in, people could start using it straight away by adding -fuse-cxa-atexit in their CFLAGS, and I'll be building a new release of the compiler with it on by default (need to fix those script perms and the java alternatives anyway, so I'll do them all in one). The ramifications, such as they are, are that newly-built user DLLs won't run against old versions of the Cygwin DLL, which is just the usual thing anyway. Old user DLLs will initially continue to have this limit to the correctness of their function. For the third part of the fix, I'm going to try something a bit more tricky: if we can detect in cygwin_atexit() whether we're being called from a DLL, we can fabricate a __dso_handle value and redirect to cxa_atexit. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
perl GD - can find gd.h
Hello, Yesterday Dave Korn helped me get my gcc compiler working. Now I'm running into a new issue when trying to compile the Perl GD module. Here is the output: (1008) sirius:~/downloads/GD-2.44 $ perl Makefile.PL Notice: Type perl Makefile.PL -h for command-line option summary. Configuring for libgd version 2.0.36. Checking for stray libgd header files... ** WARNING: found gd.h header file in /usr/include/gcc/i686-pc-cygwin/4.3.4/../. ./..gd.h, but it is expected at /usr/include/gd.h. This may cause compile errors ! ** ** Possible problems found ** Included Features: GD_XPM GD_JPEG GD_FONTCONFIG GD_FREETYPE GD_PNG GD_G IF GD_GIFANIM GD_OPENPOLYGON GD_UNCLOSEDPOLY GD_ANIMGIF GD_FTCIRCLE VERSION_33 GD library used from: /usr Writing Makefile for GD Note how it says my gd.h header file was not found in /usr/include/gd.h and that it was found in /usr/include/gcc/... But oddly enough, I don't even have a /usr/include/gcc/ directory and gd.h is in fact found in /usr/include on my system. See output below: (1010) sirius:~/downloads/GD-2.44 $ ls -l /usr/include/gd.h -rw-r--r-- 1 LUPEY Administrators 32609 2009-09-15 06:14 /usr/include/gd.h (1011) sirius:~/downloads/GD-2.44 $ ls /usr/include/gcc ls: cannot access /usr/include/gcc: No such file or directory What is going on here? Is this a problem with my cygwin/gcc installation or a GD problem? Thank you for your guidance, Paul -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bash completion and symlinks problem
On Feb 1 12:51, DEWI - N. Zacharias wrote: Hi all, another problem after updating cgwin . The bash completion don't work for symlinks . assume having a /cygdrive/c/bin directory which contains symlinks to scripts in a central directory on our file sever say /cygdrive/x /centraltools/ eg. /cygdrive/c/bin/dosomething.pl - /cygdrive/x /centraltools/dosomething.pl The strange thing is, old links as well as new ones executed fine. Only they don't appear in the completion. Can someone tell me why ?? Work for me. Your symlink points to a script which has no execute permissions (if acl is set on the target mount), or the script doesn't start with a shebang. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
AW: [bulk] - Re: Bash completion and symlinks problem
Hi Corinna, Von: Corinna Vinschen [mailto:corinna-cyg...@cygwin.com] Gesendet: Montag, 1. Februar 2010 16:18 An: cygwin@cygwin.com Betreff: [bulk] - Re: Bash completion and symlinks problem On Feb 1 12:51, DEWI - N. Zacharias wrote: Hi all, another problem after updating cgwin . The bash completion don't work for symlinks . assume having a /cygdrive/c/bin directory which contains symlinks to scripts in a central directory on our file sever say /cygdrive/x /centraltools/ eg. /cygdrive/c/bin/dosomething.pl - /cygdrive/x /centraltools/dosomething.pl The strange thing is, old links as well as new ones executed fine. Only they don't appear in the completion. Can someone tell me why ?? Work for me. Your symlink points to a script which has no execute permissions (if acl is set on the target mount), or the script doesn't start with a shebang. Mount says: C: on /cygdrive/c type ntfs (text,posix=0,user,noumount,auto) X: on /cygdrive/x type nwfs (text,posix=0,user,noumount,auto) ls yields $ ls -al dosomething.pl -rw-r--r-- 1 n-zacharias Kein 94 2010-02-01 16:42 dosomething.pl Even if I use chmod 777 dosomething.pl there is no change in -rw-r--r-- Which seems to be no problem because it executes anyway. $ cat dosomething.pl #! /usr/bin/perl -w # # testscript print Hello world\n; Only the completion did not work or better the completion for execution. Kindly regards Norbert -- Dipl. Phys. Norbert Zacharias Wind Measurements Power Curve Measurements DEWI GmbH Ebertstrasse 96 26382 Wilhelmshaven Germany Tel.: +49 4421 4808 876 Fax:+49 4421 4808 843 Email: n.zachar...@dewi.de Home: http://http://www.dewi.de DEWI GmbH - Deutsches Windenergie-Institut, Wilhelmshaven Commercial Register No.: Amtsgericht Oldenburg, HRB 130241 Managing Director: Jens Peter Molly Chairman of the supervisory board: Ministerialrat Dr. Niels Kämpny P Please consider the environment before printing this email. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Xwin report and partial solution
On 02/01/2010 01:20 AM, Javier Sedano wrote: Hi, friends, yesterday I tried to run the cygwin X server, but it did not run. It cried about being unable to bind to the ipv6 address or so. Browsing the mail list I've seen several requests for help, but I have not found the solution that I applied: install the ipv6 stack. Once I installed the ipv6 stack on windows xp (the command to be run is just ipv6 install; I don't know about other versions of windows), Xwin runs without problems. I haven't seen anyone pointing to that solution. However, I'd like if the maintainer could remove such dependency... Cygwin X issues, comments, and questions should be sent to the cygwin-xfree 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? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: AW: [bulk] - Re: Bash completion and symlinks problem
On 02/01/2010 10:53 AM, DEWI - N. Zacharias wrote: Hi Corinna, Von: Corinna Vinschen [mailto:corinna-cyg...@cygwin.com] Gesendet: Montag, 1. Februar 2010 16:18 An:cygwin@cygwin.com Betreff: [bulk] - Re: Bash completion and symlinks problem On Feb 1 12:51, DEWI - N. Zacharias wrote: Hi all, another problem after updating cgwin . The bash completion don't work for symlinks . assume having a /cygdrive/c/bin directory which contains symlinks to scripts in a central directory on our file sever say/cygdrive/x /centraltools/ eg. /cygdrive/c/bin/dosomething.pl - /cygdrive/x /centraltools/dosomething.pl The strange thing is, old links as well as new ones executed fine. Only they don't appear in the completion. Can someone tell me why ?? Work for me. Your symlink points to a script which has no execute permissions (if acl is set on the target mount), or the script doesn't start with a shebang. Mount says: C: on /cygdrive/c type ntfs (text,posix=0,user,noumount,auto) X: on /cygdrive/x type nwfs (text,posix=0,user,noumount,auto) ^^^ See the recent archive threads on NetWare file systems. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: dlclose not calling destructors of static variables.
On Mon, Feb 01, 2010 at 11:46:55AM +, Andrew West wrote: On 29/01/2010 18:45, Christopher Faylor wrote: On Fri, Jan 29, 2010 at 02:30:48PM +, Andrew West wrote: On 29/01/2010 13:08, Dave Korn wrote: On 28/01/2010 11:21, Andrew West wrote: I seem to be having a problem with dlclose not calling the destructors of statically declared variables. I've attached a simple test case which I compile as follows; Thanks for the report and the STC; this should work. I'll take a look at it over the weekend or the start of next week if nobody else gets there first. Thanks for looking into this, it looks a little more complex than I first thought. I've tried calling __call_exitprocs during dlclose ( after run_dtors for the unloading library ) just to see if I was thinking along the right lines. Unfortunately this didn't work as when the destructor is registered with atexit it isn't associated with the loaded library but with the main executable. Which brings me on to the bigger problem, the static variables are registered with atexit rather than with __cxa_atexit which seems to be a violation of the C++ standard (1). Worse still gcc isn't compiled with cxa_atexit enabled. So I assume the right course of action here is to enable __cxa_atexit in gcc, and then make sure __cxa_finalize gets called when the library is unloaded? I agree with your assessment here. I've checked in a change which works around the problem you've uncovered but it is not foolproof. It should fix the immediate problem but, in the long run, I agree that gcc should be emitting code which calls __cxa_atexit. Of course I have no idea what the other ramifications of doing that might be. Hopefully Dave can enlighten us. This is in today's snapshot at http://cygwin.com/snapshots/ . cgf Hi, I checked out the changes and it still crashed for me. Digging into it the destructor for testlib fell outside of dll_end ( m.AllocationBase + m.RegionSize ). On a whim I change m.AllocationBase to m.BaseAddress and that seemed to fix it for me! The destructor ran on dlclose and the testrunner.exe didn't segfault. Could you clarify? Are you saying that your test case still failed? cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: dlclose not calling destructors of static variables.
On 01/02/2010 16:26, Christopher Faylor wrote: Could you clarify? Are you saying that your test case still failed? With the change you provided my test still failed, but changing m.AllocationBase to m.BaseAddress it worked. Unfortunately it only worked for that test cash, on trying it with a full program of mine it crashed using both AllocationBase and BaseAddress to work out the start position of the dll. On closer examination it looks like dll_beg - dll_end doesn't cover all the possible locations that atexits are registered from. I think RegionSize isn't big enough at least when I compare them to gdbs info sharedlibrary, for example: remove_dll_atexit; m.AllocationBase = 0x706c m.AllocationBase + m.RegionSize = 0x706c1000 GDB; from = 0x706c1000 to = 0x706c717c But the atexit function is registered at 0x706c10f0. Changing AllocationBase to BaseAddress worked for my test case out of pure luck, with my larger libraries it still failed. Looking at one of the libraries in my code that fails I get ( with the atexit at 0x78351c9 ) remove_dll_atexit; m.AllocationBase = 0x782 m.AllocationBase + m.RegionSize = 0x7824000 GDB; from = 0x07821000 to = 0x079159b8 With both of these examples I checked the dll using objdump and the atexit functions where in the .text portion but RegionSize never seems big enough to cover it entirely. For that last dll objdump reports the text size as 61380. Of course I could be reading objdump wrong, I've only every really used it to check exported functions. Cribbing from the gdb source code, it looks like they use BaseAddrees + 0x1000 for the start point and then call GetModuleInformation to workout the size of the module. I'm currently trying this out in dll_init.cc but for some reason GetCurrentProcess is returning -1 for me :( Andy. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fyi Apache2 notes: No space left on device / Cannot create SSLMutex
On Sun, 24 Jan 2010 23:28:19 Christopher Faylor wrote: I don't know that this site even uses Cygwin. They'd actually be pretty dumb to use Cygwin's apache on a high-volume site like that so it probably is not the case. I just thought it was an odd coincidence that I read about the same problem from the same netblock in a 60 second window. I run Cygwin apache2 on a low-ish volume site (about 30 unique visitors per day, plus the never-ending stream of bots which all public sites serve) and the latest - as of 30 Jan 2010 - Cygwin apache2 running on a new Windows 7 x64 machine eventually crashes the machine. Note that if apache2 is running but the machine is _not_ getting hits then there are no problems. As soon as httpd2 starts getting even this modest number of connections there will be problems. The machine mostly runs unattended at a remote site. After running httpd2 for about 24 hours I can no longer ssh into the machine, and often when I do get a chance to attend the machine it has crashed. The same site was served by an old XP Home box running Cygwin apache2 for years and there was never a problem. Stacey -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: dlclose not calling destructors of static variables.
On Mon, Feb 01, 2010 at 05:35:10PM +, Andrew West wrote: On 01/02/2010 16:26, Christopher Faylor wrote: Could you clarify? Are you saying that your test case still failed? With the change you provided my test still failed, but changing m.AllocationBase to m.BaseAddress it worked. Unfortunately it only worked for that test cash, on trying it with a full program of mine it crashed using both AllocationBase and BaseAddress to work out the start position of the dll. On closer examination it looks like dll_beg - dll_end doesn't cover all the possible locations that atexits are registered from. I think RegionSize isn't big enough at least when I compare them to gdbs info sharedlibrary, for example: remove_dll_atexit; m.AllocationBase = 0x706c m.AllocationBase + m.RegionSize = 0x706c1000 GDB; from = 0x706c1000 to = 0x706c717c But the atexit function is registered at 0x706c10f0. Changing AllocationBase to BaseAddress worked for my test case out of pure luck, with my larger libraries it still failed. Looking at one of the libraries in my code that fails I get ( with the atexit at 0x78351c9 ) remove_dll_atexit; m.AllocationBase = 0x782 m.AllocationBase + m.RegionSize = 0x7824000 GDB; from = 0x07821000 to = 0x079159b8 With both of these examples I checked the dll using objdump and the atexit functions where in the .text portion but RegionSize never seems big enough to cover it entirely. For that last dll objdump reports the text size as 61380. Of course I could be reading objdump wrong, I've only every really used it to check exported functions. Cribbing from the gdb source code, it looks like they use BaseAddrees + 0x1000 for the start point and then call GetModuleInformation to workout the size of the module. Yeah, duh. they == me. I should have checked gdb for this since I've already done this research once before. If you do find that this works, then I think this may fall into the realm of a non-trivial patch so it may be best to just tell me what you've found rather than provide a patch - unless you want to go through the approval process with Red Hat. Or, you can just wait for me to adapt what's in gdb to cygwin. I can do tonight when I get back to a windows system. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: dlclose not calling destructors of static variables.
On 01/02/2010 17:35, Andrew West wrote: Cribbing from the gdb source code, it looks like they use BaseAddrees + 0x1000 for the start point and then call GetModuleInformation to workout the size of the module. I'm currently trying this out in dll_init.cc but for some reason GetCurrentProcess is returning -1 for me :( -1 is a magic HANDLE constant meaning current process, that's OK! http://msdn.microsoft.com/en-us/library/ms683179(VS.85).aspx cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: dlclose not calling destructors of static variables.
On Mon, Feb 01, 2010 at 12:46:11PM -0500, Christopher Faylor wrote: On Mon, Feb 01, 2010 at 05:35:10PM +, Andrew West wrote: On 01/02/2010 16:26, Christopher Faylor wrote: Could you clarify? Are you saying that your test case still failed? With the change you provided my test still failed, but changing m.AllocationBase to m.BaseAddress it worked. Unfortunately it only worked for that test cash, on trying it with a full program of mine it crashed using both AllocationBase and BaseAddress to work out the start position of the dll. On closer examination it looks like dll_beg - dll_end doesn't cover all the possible locations that atexits are registered from. I think RegionSize isn't big enough at least when I compare them to gdbs info sharedlibrary, for example: remove_dll_atexit; m.AllocationBase = 0x706c m.AllocationBase + m.RegionSize = 0x706c1000 GDB; from = 0x706c1000 to = 0x706c717c But the atexit function is registered at 0x706c10f0. Changing AllocationBase to BaseAddress worked for my test case out of pure luck, with my larger libraries it still failed. Looking at one of the libraries in my code that fails I get ( with the atexit at 0x78351c9 ) remove_dll_atexit; m.AllocationBase = 0x782 m.AllocationBase + m.RegionSize = 0x7824000 GDB; from = 0x07821000 to = 0x079159b8 With both of these examples I checked the dll using objdump and the atexit functions where in the .text portion but RegionSize never seems big enough to cover it entirely. For that last dll objdump reports the text size as 61380. Of course I could be reading objdump wrong, I've only every really used it to check exported functions. Cribbing from the gdb source code, it looks like they use BaseAddrees + 0x1000 for the start point and then call GetModuleInformation to workout the size of the module. Yeah, duh. they == me. I should have checked gdb for this since I've already done this research once before. If you do find that this works, then I think this may fall into the realm of a non-trivial patch so it may be best to just tell me what you've found rather than provide a patch - unless you want to go through the approval process with Red Hat. Or, you can just wait for me to adapt what's in gdb to cygwin. I can do tonight when I get back to a windows system. Btw, it isn't entirely clear that GetModuleInformation will work with older versions of Windows NT so this may not be a complete solution. We do use GetModuleInformation in Cygwin but it is not in anything as crucial as this. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: dlclose not calling destructors of static variables.
On 01/02/2010 17:51, Christopher Faylor wrote: On Mon, Feb 01, 2010 at 12:46:11PM -0500, Christopher Faylor wrote: Cribbing from the gdb source code, it looks like they use BaseAddrees + 0x1000 for the start point and then call GetModuleInformation to workout the size of the module. Yeah, duh. they == me. I should have checked gdb for this since I've already done this research once before. If you do find that this works, then I think this may fall into the realm of a non-trivial patch so it may be best to just tell me what you've found rather than provide a patch - unless you want to go through the approval process with Red Hat. Or, you can just wait for me to adapt what's in gdb to cygwin. I can do tonight when I get back to a windows system. Btw, it isn't entirely clear that GetModuleInformation will work with older versions of Windows NT so this may not be a complete solution. We do use GetModuleInformation in Cygwin but it is not in anything as crucial as this. Can't we use the info in the dll struct? It has pointers to the data and bss section, we could take the max out of them and the data in the M_B_I struct. (Tell you what, I'll try it.) cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
./configure on cygwin in window
Please help me out. I have a problem to configure gcc-4.2.4 (gcc-g++-4.2.4.tar.bz2) cygwin in window. Details: Based on instruction on http://cygwin.wikia.com/wiki/How_to_install_GCC_4.3.0, I 1. Create subfolder, contrib, inside usr folder 2. Download gcc-4.2.2.tar.bz2 into /usr/contrib 3. It gennerates: /usr/local/contrib/gcc-4.2.4 /usr/local/contrib/gcc-4.2.4/gcc /usr/local/contrib/gcc-4.2.4/gcc/cp # cp is a subfolder /usr/local/contrib/gcc-4.2.4/libstdc++-v3 /usr/local/contrib/gcc-4.2.4/libstdc++-v3/config /usr/local/contrib/gcc-4.2.4/libstdc++-v3/docs /usr/local/contrib/gcc-4.2.4/libstdc++-v3/include /usr/local/contrib/gcc-4.2.4/libstdc++-v3/ 4. Then based on instruction of that link, $ mkdir build $ cd build $ ../gcc-*/configure --enable-languages=c,c++ $ make $ make install and instruction of cygwin lin, http://gcc.gnu.org/install/configure.html, % mkdir objdir % cd objdir % srcdir/configure [options] [target] I create subfolder named build, $ mkdir build, and then $ cd build 5. Now this is a problem. I can not configure it as an example,$ ../gcc-*/configure --enable-languages=c,c++ or % srcdir/configure [options] [target] My code is $ ls -- Result = usr/local/contrib -- it is current location $ ../gcc-4.2.4/configure --enable-languages=c,c++ --- Err msg = bash:../gcc-4.2.4/congigure: No such file or directory 6. I check more alert messge as below: [ First, we highly recommend that GCC be built into a separate directory from the sources which does not reside within the source tree. This is how we generally build GCC; building where srcdir == objdir should still work, but doesn't get extensive testing; building where objdir is a subdirectory of srcdir is unsupported. ] My srcdir is gcc-4.2.4 folder while my objdir is build. Paths are: usr/local/contrib/build usr/local/contrib/gcc-4.2.4 These look OK. Right? 7. Because of that error, I repeatly run this command, $ ../gcc-*/configure --enable-languages=c,c++, and $ ./gcc-*/configure --enable-languages=c,c++, on the different paths as below: # Current location (a) /usr/local/ -- then create build subfolder (b) /usr/local/contrib/ -- then create build subfolder (c) /usr/local/contrib/gcc-4.2.4 -- then create build subfolder (d) /usr/local/contrib/gcc-4.2.4/gcc -- then create build subfolder All generated the same error, No such file or directory. 8. Then I go to http://gcc.gnu.org/faq.html. There is no topic talking about the problem of configuration like me. Please help me out I spent like 4 days to do this. I feel that it is not a deep technical problem but I may miss - Some simple point like path or link issue or - The current location to run configure. However, regarding to all instructions, it does not mention any specific path to run configure. I am blank now However, I am not so such about that and I don't know how to solve it. Please provide me instruction and/or information. Thank you very much, Jasmine Ps. I am pretty much new and have no working experience in this special field. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] New: DocBook utils, DTDs, and stylesheets (30 packages)
The following packages have been added or updated for the Cygwin distribution: *** build-docbook-catalog-1.5-1 *** dblatex-0.2.10-1 *** docbook-dsssl-1.79-2 *** docbook-sgml30-3.0-1 *** docbook-sgml31-3.1-1 *** docbook-sgml40-4.0-1 *** docbook-sgml41-4.1-1 *** docbook-sgml42-4.2-1 *** docbook-sgml43-4.3-1 *** docbook-sgml44-4.4-1 *** docbook-sgml45-4.5-1 *** docbook-utils-0.6.14-1 *** docbook-xml-simple10-1.0-2 *** docbook-xml-simple11-1.1-2 *** docbook-xml412-4.1.2-2 *** docbook-xml42-4.2-4 *** docbook-xml43-4.3-2 *** docbook-xml44-4.4-2 *** docbook-xml45-4.5-1 *** docbook-xsl-1.75.2-1 *** docbook-xsl-ns-1.75.2-1 *** jadetex-3.13-1 *** libosp-devel-1.5.2-2 *** libosp5-1.5.2-2 *** libostyle-devel-1.4devel1-2 *** libostyle1-1.4devel1-2 *** openjade-1.4devel1-2 *** OpenSP-1.5.2-2 *** perl-SGMLSpm-1.03ii-2 *** sgml-common-0.6.3-3 DocBook is a schema for SGML and XML intended for technical documentation. The Cygwin distribution now includes the most common tools for building DocBook documentation, including those required to build the cygwin-doc, cygwin-x-doc, and xorg-docs packages from source. docbook-utils is the main package, providing the docbook2* commands. Installing docbook-utils will pull in all the other tools and DTDs required by its backends for building DocBook documentation. The DocBook DTDs and stylesheets are registered with the central SGML and XML catalogs by the tools in the sgml-common and build-docbook-catalog packages. Catalog registration is handled automatically with postinstall and preremove scripts. Yaakov CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: dlclose not calling destructors of static variables.
On 01/02/10 19:28, Dave Korn wrote: On 01/02/2010 17:51, Christopher Faylor wrote: On Mon, Feb 01, 2010 at 12:46:11PM -0500, Christopher Faylor wrote: Cribbing from the gdb source code, it looks like they use BaseAddrees + 0x1000 for the start point and then call GetModuleInformation to workout the size of the module. Yeah, duh. they == me. I should have checked gdb for this since I've already done this research once before. If you do find that this works, then I think this may fall into the realm of a non-trivial patch so it may be best to just tell me what you've found rather than provide a patch - unless you want to go through the approval process with Red Hat. Or, you can just wait for me to adapt what's in gdb to cygwin. I can do tonight when I get back to a windows system. Btw, it isn't entirely clear that GetModuleInformation will work with older versions of Windows NT so this may not be a complete solution. We do use GetModuleInformation in Cygwin but it is not in anything as crucial as this. Can't we use the info in the dll struct? It has pointers to the data and bss section, we could take the max out of them and the data in the M_B_I struct. (Tell you what, I'll try it.) That would be the ideal solution. I'm not looking to submit a patch to fix this, I'll leave that up to the professionals who have a better idea about the whole picture. It's just I've hit a brick wall with my code with this bug so I'm looking for some work arounds for myself. I'm going to poke around the remove_dll_atexit function again tomorrow. gdb used bfd_* functions from binutils so that's out for me, VirtualQuery seems wrong for purpose and GetModuleInformation keeps giving me a invalid handle error. Iterating over the dll list and using the per_module information seems like my best bet, and hopefully should be quite simple I think. Andy. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: dlclose not calling destructors of static variables.
On 01/02/2010 20:45, Andrew wrote: I'm not looking to submit a patch to fix this, I'll leave that up to the professionals who have a better idea about the whole picture. It's just I've hit a brick wall with my code with this bug so I'm looking for some work arounds for myself. No, really, you've been a ton of help, thanks a million. Try the patch I just posted to the cygwin-patches list, on top of current CVS: http://cygwin.com/ml/cygwin-patches/2010-q1/msg00051.html That should get you going with your current DLLs. Next step is to add the cxx abi functions. I found an old patch lying around, seems I started looking at this back in August and then lost track of it somehow (probably in the rush approaching the end of gcc stage 1, I guess), so I owe you apologies for the inconvenience. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Windows 7
I stand (actually I'm sitting) corrected. :) The reason I deleted the .sh script was because it would never run to completion on subsequent installs. I also forgot to add that I went though and selected reinstall for all my packages to avoid the problem you pointed out. It took a while, but everything is working for me. Sincerely, Brian S. Wilson === Home: (678) 376-9258 Cell: (678) 232-9357 wil...@ds.net === -- Original Message --- From: Larry Hall (Cygwin) reply-to-list-only...@cygwin.com To: cygwin@cygwin.com Sent: Sun, 31 Jan 2010 20:13:03 -0500 Subject: Re: Windows 7 On 01/29/2010 08:45 PM, Brian Wilson wrote: I had a similar problem upgrading on XP. I think my issue was related to a heap space allocation issue which prevents the shell from running during the installation. I found that failed installations left shell processes running, but not doing anything useful. Check the documentation as I believe there is a fix for the heap space issue. In my case, I killed these useless shells and that allowed the Cygwin bash shell to start up with out heap space errors. I cleaned out the /etc/postinstall directory by removing any shell scripts (rm *.sh) and rerunning the setup. Cygwin installed okay for me after that. There's no reason to remove postinstall scripts and, in fact, very good reason to not do so - your installation could be incomplete. If things are working for you and you have no complaints, there's no reason to revisit this issue but in case others reading this thread thought this would be a good thing to try, I wanted something on record that would recommend against it. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple --- End of Original Message --- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: dlclose not calling destructors of static variables.
On 01/02/2010 17:35, Andrew West wrote: But the atexit function is registered at 0x706c10f0. Changing AllocationBase to BaseAddress worked for my test case out of pure luck, with my larger libraries it still failed. I've managed to convince myself it's right actually. Looking at one of the libraries in my code that fails I get ( with the atexit at 0x78351c9 ) remove_dll_atexit; m.AllocationBase = 0x782 m.AllocationBase + m.RegionSize = 0x7824000 GDB; from = 0x07821000 to = 0x079159b8 Please post the output of objdump -h on this library. (If there's no problem doing so, please send me a copy of the binary off-list.) cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl GD - can find gd.h
Paul Cantalupo schrieb: Hello, Yesterday Dave Korn helped me get my gcc compiler working. Now I'm running into a new issue when trying to compile the Perl GD module. Here is the output: (1008) sirius:~/downloads/GD-2.44 $ perl Makefile.PL Notice: Type perl Makefile.PL -h for command-line option summary. Configuring for libgd version 2.0.36. Checking for stray libgd header files... ** WARNING: found gd.h header file in /usr/include/gcc/i686-pc-cygwin/4.3.4/../. ./..gd.h, but it is expected at /usr/include/gd.h. This may cause compile errors ! ** ** Possible problems found ** Included Features: GD_XPM GD_JPEG GD_FONTCONFIG GD_FREETYPE GD_PNG GD_G IF GD_GIFANIM GD_OPENPOLYGON GD_UNCLOSEDPOLY GD_ANIMGIF GD_FTCIRCLE VERSION_33 GD library used from: /usr Writing Makefile for GD Note how it says my gd.h header file was not found in /usr/include/gd.h and that it was found in /usr/include/gcc/... But oddly enough, I don't even have a /usr/include/gcc/ directory and gd.h is in fact found in /usr/include on my system. See output below: (1010) sirius:~/downloads/GD-2.44 $ ls -l /usr/include/gd.h -rw-r--r-- 1 LUPEY Administrators 32609 2009-09-15 06:14 /usr/include/gd.h (1011) sirius:~/downloads/GD-2.44 $ ls /usr/include/gcc ls: cannot access /usr/include/gcc: No such file or directory What is going on here? Is this a problem with my cygwin/gcc installation or a GD problem? Thank you for your guidance, Cannot reproduce. You need libgd-devel of course. Then perl Makefile.PL make works fine for me. make test fails at test 10, but this error is bogus. It's comparing the generated jpeg to a stored jpeg, the generated jpeg is perfectly fine. make install is fine. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ./configure on cygwin in window platform
On 2/1/2010 21:49, J J wrote: Please help me out. I spent for three days but I still could install gcc in window on cygwin. Problem is I could not install gcc file, (mingw-w64-trunk-snapshot-20091222.tar.bz2), on cygwin in window platform. I would like to unpack and intall gcc (mingw-w64-trunk-snapshot-20091222.tar.bz2) on cygwin on window platform. I follow instruction posted on http://cygwin.wikia.com/wiki/How_to_install_GCC_4.3.0. The problem I have found out is I could not process the configure step as below. The result shows No such file or directory Steps: $ mkdir build $ cd build $ ../gcc-*/configure --enable-languages=c,c++ $ make $ make install May it be because of (1) setting srcdir or objdir non-correctly or (2) else ? What I have done are: 1. Download gcc file and load it into /usr/build. Build subfolder is created by me. -- ( equal to $ mkdir build and $ cd build) 2. Unpack gcc tar.bz2 file (mingw-w64-trunk-snapshot-20091222.tar.bz2) on that location. -- It generates trunk subfolder that contains some subfolder too. 3. $mkdir build and $cd build -- current location is urs/build 4. $ ../trunk/configure --enable-languages=c,c++ -- It does not work. Error = No such file or directory Comparing to what you recommend on http://gcc.gnu.org/install/configure.html , To configure GCC: % mkdir objdir % cd objdir % srcdir/configure [options] [target] You mentions that objdir can not be a subdirectory of srcdir. This is why I tried one more time with the different folder and the same level under usr folder. What I did are: 1. Download gcc (mingw-w64-trunk-snapshot-20091222.tar.bz2) for window platform again into usr/tmp 2. Unpack it in the usr/tmp/. The path result are approximately usr/tmp/trunk/mingw..1* usr/tmp/trunk/mingw..2* usr/tmp/trunk/mingw..3* usr/tmp/trunk/mingw..4* 3. $cd build -- under usr folder -- current location is usr/build -- build is already created by me on the previous work. 4 command to configure - $../mingw-w64-trunk-snapshot-20091222.tar.bz2/configure --enable-language=c,c++ -- Show error msg = No such file or directory 5. Try $ ../trunk/mingw-w64-trunk-snapshot-20091222.tar.bz2/configure --enable-language=c,c++ -- Show error msg = No such file or directory. Please help me out. I don't why I could not and thank you very much, Jasmine Ps. I am pretty much new with cygwin and this is my first time. Hi, you've unpacked it to usr/tmp/trunk..., in usr/build, use ../trunk /.../mingw... instead. You have also forgot to set --target, please read the mingw-w64 build instructions more carefully. I suggest you read http://gd.tuwien.ac.at/linuxcommand.org/index.php. It would help a new user like you to make sense of the CLI environment. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ./configure on cygwin in window platform
On Tue, Feb 02, 2010 at 08:14:48AM +0800, JonY wrote: I suggest you read http://gd.tuwien.ac.at/linuxcommand.org/index.php. It would help a new user like you to make sense of the CLI environment. I would also suggest that you take this discussion elsewhere. This isn't really fodder for this mailing list. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cppunit: rebuild for gcc4
On 12/01/2010 02:51, Yaakov (Cygwin/X) wrote: Ross, Could you please build the lateset cppunit with gcc4? The last release was built with gcc3 and does not work with a gcc4-compiled package. Thanks, Yaakov Ping? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
tidy: update, packaging
Lapo, The 'tidy' package, for which you are listed as the maintainer, has not been updated in quite some time, and more recent versions are required in most cases nowadays. Would you be able to update this package in the near future? BTW, I have the current version in Ports, if that would be of help: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/libs/tidy/ The .cygport also created separate lib and devel packages. Thanks, Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Xwin report and partial solution
2010/2/1 Larry Hall (Cygwin) reply-to-list-only...@cygwin.com: On 02/01/2010 01:20 AM, Javier Sedano wrote: However, I'd like if the maintainer could remove such dependency... Cygwin X issues, comments, and questions should be sent to the cygwin-xfree list. Uhm... maybe that's why I didn't find an answer here? ;-) Thank's, I'll mail there. -- -- Javier Sedano javier.sed...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fyi Apache2 notes: No space left on device / Cannot create SSLMutex
On Mon, February 1, 2010 9:40:47 AM I wrote: I run Cygwin apache2 on a low-ish volume site (about 30 unique visitors per day, plus the never-ending stream of bots which all public sites serve) and the latest - as of 30 Jan 2010 - Cygwin apache2 running on a new Windows 7 x64 machine eventually crashes the machine. Taking a quick peek into a massive /var/log/apache2/error_log I see the following repeating until I arrived and rebooted: [Sun Jan 31 17:37:47 2010] [warn] (125)Cannot assign requested address: connect to listener on 0.0.0.0:80 [Sun Jan 31 17:37:48 2010] [warn] (125)Cannot assign requested address: connect to listener on 0.0.0.0:80 ... The last web page correctly served, noted in access_log, was at: 71.197.232.250 - - [31/Jan/2010:17:37:40 -0800] GET /favicon.ico HTTP/1.1 200 318 - Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; GTB6.3; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; Tablet PC 2.0; OfficeLiveConnector.1.3; OfficeLivePatch.0.0) As mentioned previously if no traffic is received by httpd2 no problems are seen. Stacey -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
