Re: [ITP] gdk-pixbuf-0.22.0-1
Dr. Volker Zell wrote: ** WARNING **: Unable to load module: libcygpixbufloader-xpm.dll.so: dlopen, Win32 error 126 Maybe the module loader stuff is handled by gqview itself? Gerrit -- =^..^=
.bash_profile and spaces
Hello there!
I've looked into this list archives and haven't found this issue being
discussed before, so I've decided to post it.
It's my first time using cygwin, and I've noticed that the .bash_profile
file came with the following content:
8
if [ -e ${HOME}/.bashrc ] ; then
source ${HOME}/.bashrc
fi
8
Well, the thing is that neither this test neither the command line would
work with directories containing spaces.
I think that it's very common for windows users to have spaces on their
usernames (my case), which would automatically include a space into the
${HOME} variable.
The solution I've found to fix this issue is to set commas around both
lines, resulting in this:
8
if [ -e ${HOME}/.bashrc ] ; then
source ${HOME}/.bashrc
fi
8
What do you say about it?
Thanks,
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Felipe Franciosi [EMAIL PROTECTED]
http://www.cpad.pucrs.br/~ozzy/
Porto Alegre, RS +55-51-9123-0557
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Re: Xfce for cygwin
Mark Fisher wrote: Ralgh has made a really good script for compiling/installing/ rebuilding each part of xfce to make it easily redistributable. Just be aware that for cygwin you need to rerun autoconf/automake and use the copy of libtool that ships with cygwin (the devel one). The libtool/ltmain.sh that ship with XFCE won't work with cygwin. btw, why do you need startup-notification? I don't have that installed, but I'm up and running (with the xffm/panel caveats etc) Correct, that one is not required. But it's nice-to-have. Maarten
RE: Starting X on a second monitor - kludge that works
I tried adding -position to a simple xinit session and X bombs out with the usage command, i.e. (~/.xinitrc) fvwm2 $ xinit -- -position 100 100 it doesn't look like these paramters exist mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Earle F. Philhower III Sent: 02 December 2004 05:49 To: [EMAIL PROTECTED] Subject: Re: Starting X on a second monitor - kludge that works Howdy... At 05:38 PM 12/1/2004 +, Mark Fisher wrote: I've been trawling the archives looking for a solution to the problem of starting Xwin on a second monitor. The only way I've been able to get this to work is to use a program that allows you to send the app to a 2nd monitor. The program in question is UltraMon. If your second monitor is a different size to your primary, then no fear, just specify the size of the screen when starting x. I've just ported xfce4.2 to cygwin, and start it like this: bash --login -c /opt/xfce4/bin/startxfce4 -- -nodecoration -screen 0 1280 1024 I'm not familiar with xfce, but why not just add a -position x y option to XWin.exe such that when present and in a root-window mode it'll move the created window to whatever screen you want (via the absolute Windoze X/Y position)? That's all the UltraMon app is doing... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
_impure_ptr warning in install
[Xwin 6.8.1.0-1, Windows XP pro 5.1, experienced with linux X, not a windows or cygwin hacker] I just did a full uninstall of cygwin everything, using the setup program. Then I installed: [setup version 2.427, from mirror.mcs.anl.gov] base/ cygwin emu engine 1.5.12-1 X11/ X-start-menu-icons 1.0.3-2 X-startup-scripts 1.0.10-2 xorg-x11-base 6.8.1.0-1 net/ inetutils 1.3.2-28 interpreters/ python During the install I several times got the message: The procedure entry point _impure_ptr could not be located in cygwin1.dll Is something broken in the current release? -- George Young -- Are the gods not just? Oh no, child. What would become of us if they were? (CSL)
Shared Memory Transport
Hi, I read Shared memory transport for XFree86. http://dri.sourceforge.net/cgi-bin/moin.cgi/SharedMemoryTransport It didn't improve so much, because unix domain socket is very fast. But we don't have unix domain socket and we use inet socket, so I think shared memory transport can improve Cygwin/X performance. What do you think? zakki -- Kensuke Matsuzaki mailto:[EMAIL PROTECTED] http://peppermint.jp
Re: Shared Memory Transport
On Sat, Dec 04, 2004 at 08:49:34AM +0900, Kensuke Matsuzaki wrote: I read Shared memory transport for XFree86. http://dri.sourceforge.net/cgi-bin/moin.cgi/SharedMemoryTransport It didn't improve so much, because unix domain socket is very fast. But we don't have unix domain socket and we use inet socket, Cygwin does have unix domain sockets. They're probably not very fast, though. cgf
Re: Shared Memory Transport
Cygwin does have unix domain sockets. They're probably not very fast, though. Sorry, you are right. But cygwin_socket uses inet to emulate. It always call socket(AF_INET, ...). I don't know well where are bottlenecks, whether transport is fast enough or not. zakki
RE: Starting X on a second monitor - kludge that works
Howdy! At 01:18 PM 12/3/2004 +, you wrote: I tried adding -position to a simple xinit session and X bombs out with the usage command, i.e. (~/.xinitrc) fvwm2 $ xinit -- -position 100 100 it doesn't look like these paramters exist Nope, it doesn't yet. But adding it to XWin.exe should be a snap. I think I still have CVS access, if I can get the src compiling this weekend I'll do a commit unless AGO objects...Xwin hit such a high quality level this year I've not needed to do anything with my install for ages! Personally, I'd like to see it as an XLib -geometry format (xwin -geometry 800x600+1024+0) just for consistency... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
src/winsup/cygwin ChangeLog environ.cc
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2004-12-03 23:49:08 Modified files: winsup/cygwin : ChangeLog environ.cc Log message: * environ.cc (environ_init): Alloc space for TERM if it is not set, like all of the other environment variables. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.2603r2=1.2604 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/environ.cc.diff?cvsroot=srcr1=1.104r2=1.105
Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.
[and now the more detailed reply] On Thu, Dec 02, 2004 at 09:13:11PM -0500, Pierre A. Humblet wrote: At 11:29 PM 11/25/2004 -0500, Christopher Faylor wrote: I have downloaded and run a recent snapshot on WinME, CYGWIN_ME-4.90 hpn5170 1.5.13s(0.116/4/2) 20041125 23:34:52 i686 unknown unknown Cygwin and tried a few things. I have also gone through the diff. Here are my initial comments: - Non cygwin processes started by cygwin are not shown by ps anymore and cannot be killed. - spawn(P_DETACH) does not work correctly when spawning non-cygwin processes. This is due to using a pipe to detect process termination. - AFAIK, the only problem with the current code is if a parent process forks a process, calls setuid, and execs a non-cygwin process it is possible that the parent process won't be able to retrieve the exit value of the non-cygwin process. I assume you are referring to the use of OpenProcess to reparent, instead of duplicating the child process handle. Yes, although cygwin was already using OpenProcess for other things so if the OpenProcess method was unsafe in this case it would have been unsafe in the other case, too. I've eliminated the need for both OpenProcess's but there are still more sprinkled throughout cygwin. This patch uses very innovative methods, but IMHO the net result goes against Cygwin tradition. It decreases features (the support of non-cygwin processes) to simplify code. It's intent was only to cause problems with that one rare feature that I mentioned. I sincerely doubt that it would have caused a problem owing to the fact that cygwin was already using the same method elsewhere. The gain was code simplification and fewer synchronization points between a parent/child process. I'd hoped to see some noticeable speed improvements but I think the bottleneck lies in fork. In fact there are many design issues and choices that have been lumped together. They can be separated, at least partially, and discussed individually. 1) parent getting handle to child: A) child duplicates handle [security issue] B) parent duplicates handle C) parent opens process [access issue] 2) child termination detection A) WaitFor(child process) B) pipe [problem spawning non-cygwin processes] C) Windows select and socket [like pipes, but untested risky] 3) number of waiting threads A) one thread per 63 processes [WaitFor only] B) one thread per process [pipe or WaitFor] C) one thread for all processes [perhaps..., with select] 4) communication with parent A) common sig pipe B) process termination detection pipe 5) support for non-cygwin processes A) subproc_ready event B) don't support 6) reporting exit status A) GetExitCodeProcess only B) pinfo-exit_status + fallback with GetExitCodeProcess Here is my analysis and recommendation for the 6 issues: 1) Use B), it has no drawback And that's what is currently in use. 2) Use A), it has no drawback, although B is tempting due to its simplicity. Perhaps worth more than spawn(P_DETACH). The problem spawning non-cygwin processes was because there were bugs in my code, which is hardly surprising given how much was rewritten. In my sandbox, I've again gotten rid of the reparenting code at the cost of keeping a cygwin stub around for the case where an exec is attempted on a pure-windows program. It's almost possible to handle this without the stub and it would be nice to think that windows processes could be handled without extra process overhead, but I finally decided that it wasn't worth the amount of bookkeeping required. The net result of the way I'm doing things now should be slightly improved functionality over 1.5.12. 3) Which one is faster? In my tests, the cvs code is as fast or very slightly faster than 1.5.12 as far as wall clock time is concerned. If cygwin is smaller and the code is simpler, then I'm satisfied with the tradeoff. I suspect that most of the slowness in process creation is in fork, not in the wait for a process to die code. 4) Dictated by choice for 2) 5) Support it. I've put it back again but it isn't exactly the same. I merged the handling of subproc_ready processing under the child_info class and use the same functions in spawn, dcrt0, and fork. 6) Use B), it must be slightly faster. I'm not sure it is all that much faster but it is more foolproof a method for passing around true UNIX exit values (Hi Igor). Other points: - The on demand creation of the pid_handles is a good idea Yes, that hit me as I was reimplementing this. - The name of the waiting threads should not be sig Yep. Cut/paste error. It would be nice if the thread names were based on the pid but that's extra processing just for strace, so I just named them proc_waiter. - opening the pinfo of ppid in set_myself(), just to close parent-wr_proc_pipe, looks simple but is costly. I understand that it's
Re: check for resolv.h
Hello all,
I have prepared another version of the AC_HEADER_RESOLV autoconf macro.
Attached is a patch against CVS; I have verified that it can be used with
autoconf-2.59b, too.
I have removed sys/socket.h; I wasn't able to find a reference to a
platform where it was required to include it before resolv.h.
I have added netdb.h, since Paul Eggert reports that it is needed on
Solaris 9.
Gerrit, Reini, could you please test the macro again? (Of course, the
easiest way is to put the macro to aclocal.m4 and call AC_HEADER_RESOLV
in your configure.ac.)
Thank you in advance for your help,
Stepan Kasal
AC_DEFUN([AC_HEADER_RESOLV],
[AC_CHECK_HEADERS(sys/types.h netinet/in.h arpa/nameser.h netdb.h resolv.h,
[], [],
[[#if HAVE_SYS_TYPES_H
# include sys/types.h
#endif
#ifdef HAVE_NETINET_IN_H
# include netinet/in.h /* inet_ functions / structs */
#endif
#ifdef HAVE_ARPA_NAMESER_H
# include arpa/nameser.h /* DNS HEADER struct */
#endif
#ifdef HAVE_NETDB_H
# include netdb.h
#endif]])
])# AC_HEADER_RESOLV
2004-12-03 Stepan Kasal [EMAIL PROTECTED]
Add a specialized check for resolv.h. Thanks to Gerrit P. Haase,
Reini Urban and Paul Eggert for reporting the dependencies.
* lib/autoconf/headers.m4 (AC_HEADER_RESOLV): New macro.
* doc/autoconf.texi (AC_HEADER_RESOLV): Document it.
(AC_HEADER_STAT): @cvindex{STAT_MACROS_BROKEN}, not @acindex.
Index: doc/autoconf.texi
===
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.846
diff -u -r1.846 autoconf.texi
--- doc/autoconf.texi 29 Nov 2004 21:43:11 - 1.846
+++ doc/autoconf.texi 3 Dec 2004 09:43:08 -
@@ -4750,10 +4750,34 @@
@code{MAJOR_IN_SYSMACROS}.
@end defmac
[EMAIL PROTECTED] AC_HEADER_RESOLV
[EMAIL PROTECTED]
[EMAIL PROTECTED] HAVE_RESOLV_H
[EMAIL PROTECTED]
+Checks for header @file{resolv.h}, checking for prerequisities first.
+To properly use @file{resolv.h}, your code should contain something like
+the following:
+
[EMAIL PROTECTED]
+#if HAVE_SYS_TYPES_H
+# include sys/types.h
+#endif
+#ifdef HAVE_NETINET_IN_H
+# include netinet/in.h /* inet_ functions / structs */
+#endif
+#ifdef HAVE_ARPA_NAMESER_H
+# include arpa/nameser.h /* DNS HEADER struct */
+#endif
+#ifdef HAVE_NETDB_H
+# include netdb.h
+#endif
+#include resolv.h
[EMAIL PROTECTED] verbatim
[EMAIL PROTECTED] defmac
@defmac AC_HEADER_STAT
@acindex{HEADER_STAT}
[EMAIL PROTECTED]
[EMAIL PROTECTED] STAT_MACROS_BROKEN
@hdrindex{sys/stat.h}
If the macros @code{S_ISDIR}, @code{S_ISREG}, etc.@: defined in
@file{sys/stat.h} do not work properly (returning false positives),
Index: lib/autoconf/headers.m4
===
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/headers.m4,v
retrieving revision 1.41
diff -u -r1.41 headers.m4
--- lib/autoconf/headers.m4 1 Jun 2004 05:33:28 - 1.41
+++ lib/autoconf/headers.m4 3 Dec 2004 09:43:08 -
@@ -440,6 +440,32 @@
])# AC_HEADER_MAJOR
+# AC_HEADER_RESOLV
+#
+# According to http://www.mcsr.olemiss.edu/cgi-bin/man-cgi?resolver+3,
+# sys/types.h, netinet/in.h and arpa/nameser.h are required on IRIX.
+# netinet/in.h is needed on Cygwin, too.
+# With Solaris 9, netdb.h is required, to get symbols like HOST_NOT_FOUND.
+#
+AN_HEADER(resolv.h,[AC_HEADER_RESOLV])
+AC_DEFUN([AC_HEADER_RESOLV],
+[AC_CHECK_HEADERS(sys/types.h netinet/in.h arpa/nameser.h netdb.h resolv.h,
+ [], [],
+[[#if HAVE_SYS_TYPES_H
+# include sys/types.h
+#endif
+#ifdef HAVE_NETINET_IN_H
+# include netinet/in.h /* inet_ functions / structs */
+#endif
+#ifdef HAVE_ARPA_NAMESER_H
+# include arpa/nameser.h /* DNS HEADER struct */
+#endif
+#ifdef HAVE_NETDB_H
+# include netdb.h
+#endif]])
+])# AC_HEADER_RESOLV
+
+
# AC_HEADER_STAT
# --
# FIXME: Shouldn't this be named AC_HEADER_SYS_STAT?
--
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: Problem running windows application, using ssh command on remote unix session
Henri Irla wrote: *Situation: -Windows XP machine with cygwin and ssh installed ( new cygwin version) -Unix machine launch windows command using local or remote ssh -correct Mount point on cygwin machine (/sophos) located on unix machine -Windows command ( /sophos/setup.exe -IN -INL -update ) : no windows display, no interactive, automated process -all machine are LAN connected, no FW *Result: -Correct execution on any cygwin terminal in windows machine ccommand passed with ssh remote ( Unix or Windows remote) correct but sophos command not executed ! Any one has any idea ? How can i trap errors or log for windows command on Windows machine ? Regards I have passe some new inspections !! user sophos run connection from Unix server to remote cygwin server on XP worskstation. sophos user is real and usable user on UNIX and XP cygwin workstation. sophos directory is samba share windows/Unix directory on Unix server. when is connected on remote cygwin ; it appear as nobody user ??? Test command : /usr/local/bin/ssh -v -i /usr/local/SOPHOS/.ssh/id_dsa [EMAIL PROTECTED] cd /sophos; echo abcdef toto; ls -ail toto using su in or out command can't change nothing result ! result : file toto is created as nobody uid and gid ??? 206441 -rwxr--r--1 nobody nobody7 déc 3 12:08 toto Why ; I d'ont understand this ? thanks in advance for you help Regards -- 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 5.8.6
Yitzchak Scott-Thoennes wrote:
On Thu, Dec 02, 2004 at 03:45:08PM +0100, Gerrit P. Haase [EMAIL PROTECTED]
wrote:
Reini Urban wrote:
No need to hurry, Gerrit :)
http://search.cpan.org/~nwclark/perl-5.8.6/pod/perl586delta.pod
This arrived yesterday.
Just wanted to know a rough timeframe and what you plan to do with the
DLL name, so that I can coordinate libwin32 and the Win32::GUI upgrades.
I want to seperate Win32::GUI from libwin32, and I want to contact Rafael.
I want to change the name to cygperl_5_8.dll. Timeframe: depends on the
results of the testsuite, if all or most tests are passnig then I think
it can be uploaded the next days.
Be better to use 3 numbers still but use PERL_API_{REVI,VER,SUBVER}SION
instead of PERL_{REVI,VER,SUBVER}SION. (See patchlevel.h.) Unless there's
a length problem, maybe also append archname (cygwin-thread-multi-64int).
It should work for internal version checks and where else it is used as
is, however the DLL naming for perl is hardcoded in the wrapper perlld.
So actually it is only the DLL name that changes to enable the use of
older extensions without recompiling easily.
Gerrit
--
=^..^=
--
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/
cygwin bugzilla procps bug#575
Hi Chris, Someone entered a bugzilla bug for your procps package, without doing it on the mailinglist. http://sources.redhat.com/bugzilla/show_bug.cgi?id=575 It is formally assigned to me, so please let me know what to do with it (reject, resolve, ...), or create an account and take it over. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ -- 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: .bash_profile and spaces
On Fri, 3 Dec 2004, Felipe Franciosi wrote:
Hello there!
I've looked into this list archives and haven't found this issue being
discussed before, so I've decided to post it.
It's my first time using cygwin, and I've noticed that the .bash_profile
file came with the following content:
8
if [ -e ${HOME}/.bashrc ] ; then
source ${HOME}/.bashrc
fi
8
Well, the thing is that neither this test neither the command line would
work with directories containing spaces.
I think that it's very common for windows users to have spaces on their
usernames (my case), which would automatically include a space into the
${HOME} variable.
The solution I've found to fix this issue is to set commas around both
lines, resulting in this:
8
if [ -e ${HOME}/.bashrc ] ; then
source ${HOME}/.bashrc
fi
8
What do you say about it?
We'd say that cygwin-apps is the wrong list for this report; that the
right list is the main Cygwin list (cygwin at cygwin dot com); and that
this issue *is* in the archives of that list.
Redirecting. Please remove cygwin-apps from any further discussion on
this.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
1.5.12: TERM environment reset to cygwin after fork()
Hi all, Version: CYGWIN_NT-5.0 -- 1.5.12(0.116/4/2) -- i686 unknown unknown Cygwin I set the TERM environment variable in my application by calling setenv(). A subsequent call to getenv(TERM) yields the expected value. However, after performing a fork(), the call to getenv(TERM) returns cygwin. This is the case for both the parent and the child. Any ideas? Thanks -- -- 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: 1.5.12: TERM environment reset to cygwin after fork()
On Fri, Dec 03, 2004 at 02:35:59PM -0500, B. Scott Smith wrote: Version: CYGWIN_NT-5.0 -- 1.5.12(0.116/4/2) -- i686 unknown unknown Cygwin I set the TERM environment variable in my application by calling setenv(). A subsequent call to getenv(TERM) yields the expected value. However, after performing a fork(), the call to getenv(TERM) returns cygwin. This is the case for both the parent and the child. Any ideas? Simple test case? 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/
cron_diagnose.sh version 1.8
Attached below is version 1.8 of this diagnostic script. Thanks to Pierre A. Humblet for additional tests that check to see that the /etc/group and /etc/passwd files have valid entries for 'SYSTEM' and 'Administrators.' (Please send any replies to the mailing list, and NOT to me. Please do NOT include my email address in any replies sent to the mailing list.) --- cron_diagnose.sh will attempt to diagnose problems with cron. It will not modify any files on your computer. You might need to run the script several times. Each time that it finds a problem, it stops and displays a descriptive message. Please read the messages that the script generates, especially if it reports no errors, but you still cannot get cron to work for you. These messages should help you to report problems that occur in setting up cron, and possibly reduce the number of messages about cron that need to be sent to the mailing list. Please report the version number that this script reports so that improvements can be made to it. cron_diagnose.sh Description: cron_diagnose.sh -- 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/
1.5.12: TERM environment reset to cygwin after fork()
Hi all, Version: CYGWIN_NT-5.0 -- 1.5.12(0.116/4/2) -- i686 unknown unknown Cygwin I set the TERM environment variable in my application by calling setenv(). A subsequent call to getenv(TERM) yields the expected value. However, after performing a fork(), the call to getenv(TERM) returns cygwin. This is the case for both the parent and the child. -- I have found a big clue. If I set the TERM variable in the Windows environment prior to running my program (it can be set to anything at all), it works as expected. Any ideas? Thanks -- Code snippet: setenv(TERM, ansi, 1); /* ... blah, blah, ... */ printf(TERM is: %s\n, getenv(TERM)); /* prints ansi as expected */ int i = fork(); if (i 0) printf(Bad Business...); else if ( i 0 ) printf(parent TERM is: %s\n, getenv(TERM)); /* prints cygwin */ else printf(child TERM is: %s\n, getenv(TERM)); /* prints 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: MSVC-dll under cygwin
Reini Urban wrote: You can actually. g++ emulates the msvc vtable layout. Wow, that must be new, then. I'm not too familiar with the ABI changes that have gone in since 3.something. Thanks for the correction. (OT alert: I was under the impression that the Msft vtable layout algorithm was patented, but perhaps I'm misinformed..) -- 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: 1.5.12: TERM environment reset to cygwin after fork()
On Fri, Dec 03, 2004 at 04:21:40PM -0500, B. Scott Smith wrote: Hi all, Version: CYGWIN_NT-5.0 -- 1.5.12(0.116/4/2) -- i686 unknown unknown Cygwin I set the TERM environment variable in my application by calling setenv(). A subsequent call to getenv(TERM) yields the expected value. However, after performing a fork(), the call to getenv(TERM) returns cygwin. This is the case for both the parent and the child. -- I have found a big clue. If I set the TERM variable in the Windows environment prior to running my program (it can be set to anything at all), it works as expected. Any ideas? Provide a simple test case, that is compilable and linkable so that we can investigate your claim. -- 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: 1.5.12: TERM environment reset to cygwin after fork()
Provide a simple test case, that is compilable and linkable so that
we can investigate your claim.
#include stdio.h
int main(int argc, char **argv)
{
setenv(TERM, ansi, 1);
/* ... blah, blah, ... */
printf(TERM is: %s\n, getenv(TERM)); /* prints ansi as expected */
int i = fork();
if (i 0)
printf(Bad Business...);
else if ( i 0 )
printf(parent TERM is: %s\n, getenv(TERM));
else
printf(child TERM is: %s\n, getenv(TERM));
}
C:\dla.exe
TERM is: ansi
parent TERM is: ansi
child TERM is: cygwin
C:\dl
[EMAIL PROTECTED] $ ./a.exe
TERM is: ansi
parent TERM is: ansi
child TERM is: ansi
[EMAIL PROTECTED] $
Not sure why it would give different results from cmd.exe and from bash.
cygcheck -s output attached, but it's a windows 2000 machine with sp 4,
cygwin 1.5.12, gcc 3.3.3.
-Richard Campbell.
cygcheck.out
Description: cygcheck.out
--
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/
CGI/Apache error (User defined signal 2)
I've got apache running on a Cygwin system and have even the simplest CGI scripts producing these error messages. I'm not sending these signals (SIGUSR2)... Cygwin 1.5.12-1 Apache 1.3.29-2 For example: #!/bin/bash echo -e Content-Type: text/plain\n\n; echo PID $$, PPID $PPID -- 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: Failing to mount from nfs-server
When I add -overs=2 to the mount command, I get a permission denied error instead of the server down error. Can anyone help me? On Thu, 2 Dec 2004 15:06:08 -0800, Michael Butler [EMAIL PROTECTED] wrote: I installed the latest cygwin with nfs-server and the required support packges, along with nothing else extra. I ran nfs-server-config, changed my exports, and started the daemons in the windows services. All 3 have started but when I try to mount shared directories from a Fedora Core 2 client on the same network, I get mount to NFS server '192.168.1.2' failed: server is down. rpcinfo -p from the localhost and from the client both return the following info: program vers proto port 102 tcp111 102 udp111 132 udp 2049 nfs 132 tcp 2049 nfs 151 udp850 152 udp850 151 tcp853 152 tcp853 nmapping these ports shows each of them as open except for 850. There is no firewall software on the server machine. My exports file is as follows: /mnt/c/export/root *(ro,no_root_squash,sync) /pub*(ro,no_root_squash,sync) It seems to me as though this should be a working setup. Did I miss something? -- 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/
Suggestions
Hi, Is there some more specific place in which to give suggestions or feedback about the Cygwin pages? Thanks, Rodrigo -- 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: 1.5.12: TERM environment reset to cygwin after fork()
On Fri, Dec 03, 2004 at 04:44:01PM -0500, Richard Campbell wrote:
Provide a simple test case, that is compilable and linkable so that
we can investigate your claim.
#include stdio.h
int main(int argc, char **argv)
{
setenv(TERM, ansi, 1);
/* ... blah, blah, ... */
printf(TERM is: %s\n, getenv(TERM)); /* prints ansi as expected */
int i = fork();
if (i 0)
printf(Bad Business...);
else if ( i 0 )
printf(parent TERM is: %s\n, getenv(TERM));
else
printf(child TERM is: %s\n, getenv(TERM));
}
C:\dla.exe
TERM is: ansi
parent TERM is: ansi
child TERM is: cygwin
Thanks. That pinpointed the problem it will be fixed in the next release.
Ordinarily I'd say try a snapshot but apparently I've destabilized things
a bit in snapshot land so I wouldn't recommend using a snapshot right now.
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: Failing to mount from nfs-server
On Dec 3, 2004, at 3:00 PM, Michael Butler wrote: When I add -overs=2 to the mount command, I get a permission denied error instead of the server down error. Can anyone help me? On Thu, 2 Dec 2004 15:06:08 -0800, Michael Butler [EMAIL PROTECTED] wrote: I installed the latest cygwin with nfs-server and the required support packges, along with nothing else extra. I ran nfs-server-config, changed my exports, and started the daemons in the windows services. All 3 have started but when I try to mount shared directories from a Fedora Core 2 client on the same network, I get mount to NFS server '192.168.1.2' failed: server is down. rpcinfo -p from the localhost and from the client both return the following info: program vers proto port 102 tcp111 102 udp111 132 udp 2049 nfs 132 tcp 2049 nfs 151 udp850 152 udp850 151 tcp853 152 tcp853 nmapping these ports shows each of them as open except for 850. There is no firewall software on the server machine. My exports file is as follows: /mnt/c/export/root *(ro,no_root_squash,sync) /pub*(ro,no_root_squash,sync) It seems to me as though this should be a working setup. Did I miss something? Try removing the '*' in the exports file and restarting things. I've had problems with using only the *. Your milage may vary though. -- 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/ Enjoy, Peter --- A Møøse once bit my sister -- 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: Failing to mount from nfs-server
On Dec 3, 2004, at 4:00 PM, Michael Butler wrote: How silly of me to not try this earlier. Success! Thank you. On another note, is it a bug that * does not work in this version of nfsd/mountd/whatever? I have had it work with every other version of nfsd. I think that it would be a bug. The manual says a * should match any machine, but it doesn't on cygwin. Mike On Fri, 3 Dec 2004 15:52:11 -0800, Peter Rehley [EMAIL PROTECTED] wrote: Try removing the '*' in the exports file and restarting things. I've had problems with using only the *. Your milage may vary though. Enjoy, Peter --- A Møøse once bit my sister Enjoy, Peter --- A Møøse once bit my sister -- 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/
