date:20031013

On Mon, Oct 13, 2003 at 10:19:08PM -0400, Christopher Faylor wrote:
> Apparently you decided to bcc me on this email.
> 
> IIRC, I asked not to receive personal email from you on this subject.  I
> suggested that you continue your discussion in the cygwin mailing list
> and it should be obvious to anyone that I read the mailing list and was
> reading this thread, in fact.  So, there was no need to do this even
> if I hadn't explicitly asked you to not send me personal mail.
> 
> Do not send me personal email about cygwin again.

I bcc'ed you about this because it was your decision about the email was in large part
responsible for the somewhat antagonistic tone that developed in the thread on 
[EMAIL PROTECTED]  Frankly the terseness of it (saying 'it will never happen' before
even understanding what 'it' was), and the discourtesy expressed in your 
attitude pissed me off and it is not at all professional.

And no, this email - *and the last email* - was not about cygwin, it was about conduct.
You hold the keys to some sort of power, the power to enter the developer's list, the 
power to patch cygwin effectively. For you to issue a blanket statement that I am not 
to communicate to you about cygwin and hence never to enter that list is a disabuse of 
power.  The BCC was a courtesy to you, just to remind you who said the 'blanket no' and
perhaps to allow you to re-think your position.

And FYI -  I agreed with Larry Hall. cygwin-patches is probably the better mailing list
for me; it fits more with what I want to do. If you had pointed me in that direction 
(after a couple of friendly questions on my part rather than an all-out blanket 
statement
saying 'it will never happen') a flame war could have been averted.

And even though this is in its essence, a personal letter, I will obey the letter of 
your 
law, and post it publicly. In a way, its probably better this way. Power issues are a 
matter of public import, and this is a hell of a power issue.

Ed

--
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: gcc -dM -E -xc /dev/null & g++ -dM -E -xc /dev/null

2003-10-13 Thread Alex Vinokur


"Ross Smith" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> Rick Rankin wrote:
> > --- Christopher Faylor <[EMAIL PROTECTED]> wrote:
> >
> >>On Mon, Oct 13, 2003 at 07:22:28AM +0200, Alex Vinokur wrote:
> >>
> >>>gcc -dM -E -xc /dev/null
> >>> and
> >>>g++ -dM -E -xc /dev/null
> >>> produce the same output.
> >>>
> >>>Is this a feature or a bug?
> >>
> >>It is not a bug.  Try it on linux.
> >>
> >>
> >>>How can one know that g++ (not gcc) is invoked?
> >>
> >>Isn't the __cplusplus define a feature of c++?  I'm too lazy to check if this
> >>is a g++ extension but I'd be surprised if it was.
> >
> > Yes, it's defined in section 16.8 (Predefined macro names) of the ANSI/ISO
> > standard.
>
> The original poster was using the -xc flag, which tells the compiler
> that the following source file is to be read as C regardless of the
> file name. I'd expect exactly the same preprocessor output from both
> frontends in that case.
>
[snip]

Thanks.

Now it seems to be OK.

$ g++ -dM -E -xc /dev/null > out_c

$ g++ -dM -E -xc++ /dev/null > out_c++

$ diff out_c out_c++
$ diff out_c out_c++
28a29
> #define __EXCEPTIONS 1
30a32
> #define __GXX_WEAK__ 1
43a46
> #define __WCHAR_UNSIGNED__ 1
50a54
> #define __cplusplus 1
51a56
> #define __DEPRECATED 1
53a59
> #define __GNUG__ 3


 =
   Alex Vinokur
 mailto:[EMAIL PROTECTED]
 http://mathforum.org/library/view/10978.html
 news://news.gmane.org/gmane.comp.lang.c++.perfometer
   =





--
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: merging mingw and cygwin

2003-10-13 Thread Christopher Faylor

On Mon, Oct 13, 2003 at 05:48:47PM -0500, Brian Ford wrote:
>On Mon, 13 Oct 2003, Edward Peschko wrote:
>>And anyways, the version numbers in itself are enough to warrant a
>>merge.  Coordinate releases of mingw and cygwin, and the version issues
>>go away.
>>
>Cygwin itself doesn't "coordinate releases".  By that I mean Cygwin,
>w32api, gcc, mingw gcc, etc.  are never release together as a package.
>Each is updated on its own schedule.

AFAIK, mingw doesn't coordinate releases either.

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: OT: Re: merging mingw and cygwin

2003-10-13 Thread Christopher Faylor

On Mon, Oct 13, 2003 at 05:35:38PM -0700, Paul G. wrote:
>Mingw is not included with Msys.  Msys "can use" and "is capable of
>_recognizing_", Mingw.  Msys != Mingw.  Msys does not need Mingw to
>develop anything.
>
>Mingw and Msys are OT for this list.

Bingo.  Paul is right.  Also Mingw doesn't need Msys to develop
anything.

cgf

(and you thought the only thing I ever did was disagree with you)

--
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: Trouble compiling with gcc 3.3.1-2

Thanks for the hand holding. I think I've nailed
the problem by running 'gcc -v'

It seemed to have been linking in an older version
of cygwin crt0.o, which was causing the trouble.

Thanks again!

> -Original Message-
> From: Larry Hall [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 13, 2003 7:24 PM
> To: Cygwin List; [EMAIL PROTECTED]
> Subject: Re: Trouble compiling with gcc 3.3.1-2
> 
> 
> At 10:12 PM 10/13/2003, Larry Hall you wrote:
> >At 10:34 PM 10/13/2003, Pankaj K Garg you wrote:
> >>I'm having the following trouble compiling
> >>even the simplest programs with gcc:
> >>
> >>$ gcc tmp.c
> >>/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/libgcc.a(w32-shared-pt
> r.o)(.text+0x189): 
> >>undefined reference to `_pthread_atfork'
> >>collect2: ld returned 1 exit status
> >>
> >>The gcc version we are using is:
> >>$ gcc -v
> >>Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/specs
> >>Configured with: /netrel/src/gcc-3.3.1-2/configure 
> --enable-languages=c,c++,f77,
> >>java --enable-libgcj --enable-threads=posix 
> --with-system-zlib --enable-nls --wi
> >>thout-included-gettext --enable-interpreter 
> --enable-sjlj-exceptions --disable-v
> >>ersion-specific-runtime-libs --enable-shared 
> --build=i686-pc-linux --host=i686-p
> >>c-cygwin --target=i686-pc-cygwin --prefix=/usr 
> --exec-prefix=/usr --sysconfdir=/
> >>etc --libdir=/usr/lib --includedir=/nonexistent/include 
> --libexecdir=/usr/sbin
> >>Thread model: posix
> >>gcc version 3.3.1 (cygming special)
> >>
> >>Will appreciate any suggestions.
> >
> >
> >OK, sometimes persistence pays off (the rest of the time it 
> just p*sses
> >people off ;-) )
> >
> >If the installation of gcc and friends didn't work the first time, I 
> >suggest you reinstall.  But before you do that, I'd first recommend
> >you review /var/log/setup.log* to see if there's any hint there as to
> >why the installation didn't work the first time.  If this and/or the
> >reinstallation doesn't help, read 
 and
>provide the information requested before sending any follow-up message
>to the list.  In particular, you should provide the "simple program".


OK, so you did provide the "simple program" in your first post.  I 
glossed over that.  However, it's not too much help since

int main(){return(0);}

compiles fine here.  Of course, I don't have the include file so I omitted
it from my test.  I'm guessing that's the source of your trouble.  Clearly, 
your attempt thinks it needs pthreads, though it's not clear why.  The rest 
of my original response still applies.  There really isn't any information 
that you've given that's helpful in tracking down your problem so you need 
to investigate a little more and report back with the specifics mentioned 
if you don't see the solution.


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
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: Trouble compiling with gcc 3.3.1-2

OK.  Why are you running from the MKS shell?  I think you're 
getting some weird interaction here.  Try pulling references to 
MKS out of your path.  Run from /bin/bash as cygwin.bat gives you.
This is the only difference of significance I can see (i.e. your
program compiled fine for me).

Larry


At 11:20 PM 10/13/2003, Pankaj K Garg you wrote:
>Thanks.
>
>I did re-install gcc, with the same result. The log file doesn't
>provide any clue either.
>
>Here's the program 'tmp.c'
>
>#include 
>int main(int argc, char *argv[])
>{
>  printf("Hello World\n");
>}
>
>Here's a run from 'cygcheck':
>
>Cygwin Win95/NT Configuration Diagnostics
>Current System Time: Mon Oct 13 19:21:41 2003
>
>Windows NT Ver 4.0 Build 1381 Service Pack 6
>
>Path:   D:\cygwin\usr\local\bin
>D:\cygwin\bin
>D:\cygwin\bin
>D:\cygwin\usr\X11R6\bin
>c:\Perl\bin\
>c:\pine
>c:\Perl\bin
>c:\mksnt
>c:\WINNT\system32
>c:\WINNT
>c:\EMACS2~1.1\bin
>c:\WINNT\system32
>c:\WINNT
>c:\EMACS2~1.1\bin
>d:\ORANT\BIN
>d:\Payup\Tools\OpenSSL\openssl-0.9.6\out32dll
>c:\Program Files\Rational\common
>c:\utty
>c:\Cvs
>c:\Program Files\Microsoft Visual Studio\Common\Tools\WinNT
>c:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin
>c:\Program Files\Microsoft Visual Studio\Common\Tools
>c:\Program Files\Microsoft Visual Studio\VC98\bin
>c:\CabSDK\bin
>c:\inetsdk\bin
>d:\Payup\Tools\OpenSSL\openssl-0.9.6\out32dll
>
>Output from D:\cygwin\bin\id.exe (nontsec)
>UID: 1000(garg) GID: 513(None)
>513(None)
>
>Output from D:\cygwin\bin\id.exe (ntsec)
>UID: 1000(garg) GID: 513(None)
>513(None)544(Administrators)
>547(Power Users) 545(Users)
>
>SysDir: C:\WINNT\System32
>WinDir: C:\WINNT
>
>GCC_EXEC_PREFIX = `c:\cygwin\lib\gcc-lib\ '
>HOME = `c:\Garg'
>MAKE_MODE = `unix'
>PWD = `/cygdrive/c/Garg/CSProjects/ZSCS/swish-e'
>USER = `garg'
>
>COMPUTERNAME = `ZEEWIN'
>COMSPEC = `C:\WINNT\system32\cmd.exe'
>CVS_RSH = `ssh'
>HOMEDRIVE = `C:'
>HOMEPATH = `\Garg'
>HOSTNAME = `zeewin'
>INCLUDE = `C:\Program Files\Microsoft Visual Studio\VC98\atl\include;C:\Program
>Files\Microsoft Visual Studio\VC98\mfc\include;C:\Program Files\Microsoft Visual
>Studio\VC98\include'
>INFOPATH =
>`/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/sta
>ble/info:'
>LIB = `C:\Program Files\Microsoft Visual Studio\VC98\mfc\lib;C:\Program
>Files\Microsoft Visual
>Studio\VC98\lib;C:\perl\lib\core;d:\Payup\Tools\OpenSSL\openssl-0.9.6\out32dll'
>LOGONSERVER = `\\ZEEWIN'
>MANPATH =
>`/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man'
>MSDEVDIR = `C:\Program Files\Microsoft Visual Studio\Common\MSDev98'
>NUMBER_OF_PROCESSORS = `1'
>OLDPWD = `/cygdrive/c/Garg'
>OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
>OS = `Windows_NT'
>PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
>PROCESSOR_ARCHITECTURE = `x86'
>PROCESSOR_IDENTIFIER = `x86 Family 6 Model 7 Stepping 2, GenuineIntel'
>PROCESSOR_LEVEL = `6'
>PROCESSOR_REVISION = `0702'
>PROMPT = `$P$G'
>PS1 = `\[\033]0;\w\007
>[EMAIL PROTECTED] \[\033[33m\w\033[0m\]
>$ '
>ROOTDIR = `C:/'
>SHELL = `C:/mksnt/sh.exe'
>SHLVL = `1'
>SYSTEMDRIVE = `C:'
>SYSTEMROOT = `C:\WINNT'
>TEMP = `c:\TEMP'
>TERM = `cygwin'
>TMP = `c:\TEMP'
>TMPDIR = `c:\TEMP'
>USERDOMAIN = `ZEEWIN'
>USERNAME = `garg'
>USERPROFILE = `C:\WINNT\Profiles\garg'
>WINDIR = `C:\WINNT'
>_ = `/usr/bin/cygcheck'
>
>HKEY_CURRENT_USER\Software\Cygnus Solutions
>HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
>HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
>  (default) = `/cygdrive'
>  cygdrive flags = 0x0022
>HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
>HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start
>Menu\&Programs\Cygnus Solutions
>  (default) = (unsupported type)
>HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
>HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
>HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
>  (default) = `/cygdrive'
>  cygdrive flags = 0x0022
>HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
>  (default) = `D:\cygwin'
>  flags = 0x000a
>HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
>  (default) = `D:\cygwin/bin'
>  flags = 0x000a
>HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
>  (default) = `D:\cygwin/lib'
>  flags = 0x000a
>HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options
>
>a:  fd   N/AN/A
>c:  hd  NTFS4016Mb  98% CP CS UN PA FC
>d:  hd  NTFS4016Mb  71% CP CS UN PA FC Garg's Disk 2
>e:  fd   N/AN/A
>f:  cd   N/AN/A
>
>.  /cygdrive  userbinmode,cygdrive
>D:\cygwin  /  system  binmode
>D:\cygwin/bin  /usr/bin   system  binmode
>D:\cygwin/lib  /usr/lib   system  binmode
>.  /cygdrive  system  binmode,cygdrive
>
>Found: D:\cygwin\bin\a

Re: setup hangs during postinstall

2003-10-13 Thread Christopher Faylor

On Mon, Oct 13, 2003 at 12:22:12PM -0500, Brian Ford wrote:
>Since setup must be launched from explorer to hang, I set
>CYGWIN_DEBUG=cygpath in my system environment variables and rebooted.  To
>make sure it worked, I launched a bash under rxvt and did a "cygpath -S".
>Up popped the gdb cmd shell.  But, under setup, no dice.

Are you saying that there was no popup?  That would imply that CYGWIN_DEBUG
is not in the environment.  You could just hack on the code in dcrt0.cc to
automatically pop up a gdb when command line contains cygpath, as a temporary
measure, of course.

>cygpath hangs just like before.  The stack trace looks a little different.
>Note that I have not had time to hand decode the holes in the trace yet,
>but it looks to me like a startup problem before the CYGWIN_DEBUG
>handling code.  A "fork exec copy" problem maybe?  I know that's vague,
>but I think you know what I mean.

The stack trace below is from a process that is running cygpath not from cygpath
itself.

So, there should be another cygpath process which is stuck, as you say,
prior to the point where it has "acquired the pid".  You should be able
to see it with a "ps -W".

cgf

>(gdb) info threads
>  3 thread 213.0xb5  0x77f7645d in _system_dlls__ ()
>  2 thread 213.0xd3  0x77f67fc7 in _system_dlls__ ()
>* 1 thread 213.0xd7  0x77f6838b in _system_dlls__ ()
>(gdb)i
>#0  0x77f6838b in _system_dlls__ ()
>#1  0x77f1d06a in _system_dlls__ ()
>#2  0x61091027 in WFMO (nCount=3, lpHandles=0x1, fWaitAll=2147348480,
>dwMilliseconds=4294967295)
>at ../../../../cygwin/winsup/cygwin/sigproc.cc:1248
>#3  0x6109344b in spawn_guts(char const*, char const* const*, char const* const*, 
>int) (prog_arg=0xa044050 "/usr/bin/cygpath.exe", argv=0xa044b88,

--
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: Trouble compiling with gcc 3.3.1-2

Thanks.

I did re-install gcc, with the same result. The log file doesn't
provide any clue either.

Here's the program 'tmp.c'

#include 
int main(int argc, char *argv[])
{
  printf("Hello World\n");
}

Here's a run from 'cygcheck':

Cygwin Win95/NT Configuration Diagnostics
Current System Time: Mon Oct 13 19:21:41 2003

Windows NT Ver 4.0 Build 1381 Service Pack 6

Path:   D:\cygwin\usr\local\bin
D:\cygwin\bin
D:\cygwin\bin
D:\cygwin\usr\X11R6\bin
c:\Perl\bin\
c:\pine
c:\Perl\bin
c:\mksnt
c:\WINNT\system32
c:\WINNT
c:\EMACS2~1.1\bin
c:\WINNT\system32
c:\WINNT
c:\EMACS2~1.1\bin
d:\ORANT\BIN
d:\Payup\Tools\OpenSSL\openssl-0.9.6\out32dll
c:\Program Files\Rational\common
c:\utty
c:\Cvs
c:\Program Files\Microsoft Visual Studio\Common\Tools\WinNT
c:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin
c:\Program Files\Microsoft Visual Studio\Common\Tools
c:\Program Files\Microsoft Visual Studio\VC98\bin
c:\CabSDK\bin
c:\inetsdk\bin
d:\Payup\Tools\OpenSSL\openssl-0.9.6\out32dll

Output from D:\cygwin\bin\id.exe (nontsec)
UID: 1000(garg) GID: 513(None)
513(None)

Output from D:\cygwin\bin\id.exe (ntsec)
UID: 1000(garg) GID: 513(None)
513(None)544(Administrators)
547(Power Users) 545(Users)

SysDir: C:\WINNT\System32
WinDir: C:\WINNT

GCC_EXEC_PREFIX = `c:\cygwin\lib\gcc-lib\ '
HOME = `c:\Garg'
MAKE_MODE = `unix'
PWD = `/cygdrive/c/Garg/CSProjects/ZSCS/swish-e'
USER = `garg'

COMPUTERNAME = `ZEEWIN'
COMSPEC = `C:\WINNT\system32\cmd.exe'
CVS_RSH = `ssh'
HOMEDRIVE = `C:'
HOMEPATH = `\Garg'
HOSTNAME = `zeewin'
INCLUDE = `C:\Program Files\Microsoft Visual Studio\VC98\atl\include;C:\Program
Files\Microsoft Visual Studio\VC98\mfc\include;C:\Program Files\Microsoft Visual
Studio\VC98\include'
INFOPATH =
`/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/sta
ble/info:'
LIB = `C:\Program Files\Microsoft Visual Studio\VC98\mfc\lib;C:\Program
Files\Microsoft Visual
Studio\VC98\lib;C:\perl\lib\core;d:\Payup\Tools\OpenSSL\openssl-0.9.6\out32dll'
LOGONSERVER = `\\ZEEWIN'
MANPATH =
`/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man'
MSDEVDIR = `C:\Program Files\Microsoft Visual Studio\Common\MSDev98'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/cygdrive/c/Garg'
OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
OS = `Windows_NT'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 7 Stepping 2, GenuineIntel'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0702'
PROMPT = `$P$G'
PS1 = `\[\033]0;\w\007
[EMAIL PROTECTED] \[\033[33m\w\033[0m\]
$ '
ROOTDIR = `C:/'
SHELL = `C:/mksnt/sh.exe'
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINNT'
TEMP = `c:\TEMP'
TERM = `cygwin'
TMP = `c:\TEMP'
TMPDIR = `c:\TEMP'
USERDOMAIN = `ZEEWIN'
USERNAME = `garg'
USERPROFILE = `C:\WINNT\Profiles\garg'
WINDIR = `C:\WINNT'
_ = `/usr/bin/cygcheck'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start
Menu\&Programs\Cygnus Solutions
  (default) = (unsupported type)
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `D:\cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `D:\cygwin/bin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `D:\cygwin/lib'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

a:  fd   N/AN/A
c:  hd  NTFS4016Mb  98% CP CS UN PA FC
d:  hd  NTFS4016Mb  71% CP CS UN PA FC Garg's Disk 2
e:  fd   N/AN/A
f:  cd   N/AN/A

.  /cygdrive  userbinmode,cygdrive
D:\cygwin  /  system  binmode
D:\cygwin/bin  /usr/bin   system  binmode
D:\cygwin/lib  /usr/lib   system  binmode
.  /cygdrive  system  binmode,cygdrive

Found: D:\cygwin\bin\awk.exe
Found: c:\mksnt\awk.exe
Warning: D:\cygwin\bin\awk.exe hides c:\mksnt\awk.exe
Found: D:\cygwin\bin\bash.exe
Found: D:\cygwin\bin\cat.exe
Found: c:\mksnt\cat.exe
Warning: D:\cygwin\bin\cat.exe hides c:\mksnt\cat.exe
Found: D:\cygwin\bin\cp.exe
Found: c:\mksnt\cp.exe
Warning: D:\cygwin\bin\cp.exe hides c:\mksnt\cp.exe
Found: D:\cygwin\bin\cpp.exe
Found: D:\cygwin\bin\find.exe
Found: c:\mksn

--disable-checking in GCC ?

2003-10-13 Thread Frédéric L. W. Meunier

I read it makes significant differences for compile times when
GCC is configured with --disable-checking, but 3.3.1-2 doesn't
return it with gcc -v. Does it make any difference on Cygwin ?
It certainly does on Linux.

-- 
How to contact me - http://www.pervalidus.net/contact.html

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Trouble compiling with gcc 3.3.1-2

At 10:12 PM 10/13/2003, Larry Hall you wrote:
>At 10:34 PM 10/13/2003, Pankaj K Garg you wrote:
>>I'm having the following trouble compiling
>>even the simplest programs with gcc:
>>
>>$ gcc tmp.c
>>/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/libgcc.a(w32-shared-ptr.o)(.text+0x189): 
>>undefined reference to `_pthread_atfork'
>>collect2: ld returned 1 exit status
>>
>>The gcc version we are using is:
>>$ gcc -v
>>Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/specs
>>Configured with: /netrel/src/gcc-3.3.1-2/configure --enable-languages=c,c++,f77,
>>java --enable-libgcj --enable-threads=posix --with-system-zlib --enable-nls --wi
>>thout-included-gettext --enable-interpreter --enable-sjlj-exceptions --disable-v
>>ersion-specific-runtime-libs --enable-shared --build=i686-pc-linux --host=i686-p
>>c-cygwin --target=i686-pc-cygwin --prefix=/usr --exec-prefix=/usr --sysconfdir=/
>>etc --libdir=/usr/lib --includedir=/nonexistent/include --libexecdir=/usr/sbin
>>Thread model: posix
>>gcc version 3.3.1 (cygming special)
>>
>>Will appreciate any suggestions.
>
>
>OK, sometimes persistence pays off (the rest of the time it just p*sses
>people off ;-) )
>
>If the installation of gcc and friends didn't work the first time, I 
>suggest you reinstall.  But before you do that, I'd first recommend
>you review /var/log/setup.log* to see if there's any hint there as to
>why the installation didn't work the first time.  If this and/or the
>reinstallation doesn't help, read  and
>provide the information requested before sending any follow-up message
>to the list.  In particular, you should provide the "simple program".


OK, so you did provide the "simple program" in your first post.  I 
glossed over that.  However, it's not too much help since

int main(){return(0);}

compiles fine here.  Of course, I don't have the include file so I omitted
it from my test.  I'm guessing that's the source of your trouble.  Clearly, 
your attempt thinks it needs pthreads, though it's not clear why.  The rest 
of my original response still applies.  There really isn't any information 
that you've given that's helpful in tracking down your problem so you need 
to investigate a little more and report back with the specifics mentioned 
if you don't see the solution.


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
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: Trouble compiling with gcc 3.3.1-2

2003-10-13 Thread Lapo Luchini

Pankaj K Garg wrote:

$ gcc tmp.c
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/libgcc.a(w32-shared-ptr.o)(.text+0x189): 
undefined reference to `_pthread_atfork'
collect2: ld returned 1 exit status
 

Mhhh.. just a wild guess, but did you try with "gcc -pthread tmp.c"?

--
Lapo 'Raist' Luchini
[EMAIL PROTECTED] (PGP & X.509 keys available)
http://www.lapo.it (ICQ UIN: 529796)


--
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: Trouble compiling with gcc 3.3.1-2

At 10:34 PM 10/13/2003, Pankaj K Garg you wrote:
>I'm having the following trouble compiling
>even the simplest programs with gcc:
>
>$ gcc tmp.c
>/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/libgcc.a(w32-shared-ptr.o)(.text+0x189): 
>undefined reference to `_pthread_atfork'
>collect2: ld returned 1 exit status
>
>The gcc version we are using is:
>$ gcc -v
>Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/specs
>Configured with: /netrel/src/gcc-3.3.1-2/configure --enable-languages=c,c++,f77,
>java --enable-libgcj --enable-threads=posix --with-system-zlib --enable-nls --wi
>thout-included-gettext --enable-interpreter --enable-sjlj-exceptions --disable-v
>ersion-specific-runtime-libs --enable-shared --build=i686-pc-linux --host=i686-p
>c-cygwin --target=i686-pc-cygwin --prefix=/usr --exec-prefix=/usr --sysconfdir=/
>etc --libdir=/usr/lib --includedir=/nonexistent/include --libexecdir=/usr/sbin
>Thread model: posix
>gcc version 3.3.1 (cygming special)
>
>Will appreciate any suggestions.


OK, sometimes persistence pays off (the rest of the time it just p*sses
people off ;-) )

If the installation of gcc and friends didn't work the first time, I 
suggest you reinstall.  But before you do that, I'd first recommend
you review /var/log/setup.log* to see if there's any hint there as to
why the installation didn't work the first time.  If this and/or the
reinstallation doesn't help, read  and
provide the information requested before sending any follow-up message
to the list.  In particular, you should provide the "simple program".



--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
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/

Trouble compiling with gcc 3.3.1-2

I'm having the following trouble compiling
even the simplest programs with gcc:

$ gcc tmp.c
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/libgcc.a(w32-shared-ptr.o)(.text+0x189): 
undefined reference to `_pthread_atfork'
collect2: ld returned 1 exit status

The gcc version we are using is:
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/specs
Configured with: /netrel/src/gcc-3.3.1-2/configure --enable-languages=c,c++,f77,
java --enable-libgcj --enable-threads=posix --with-system-zlib --enable-nls --wi
thout-included-gettext --enable-interpreter --enable-sjlj-exceptions --disable-v
ersion-specific-runtime-libs --enable-shared --build=i686-pc-linux --host=i686-p
c-cygwin --target=i686-pc-cygwin --prefix=/usr --exec-prefix=/usr --sysconfdir=/
etc --libdir=/usr/lib --includedir=/nonexistent/include --libexecdir=/usr/sbin
Thread model: posix
gcc version 3.3.1 (cygming special)

Will appreciate any suggestions.

Pankaj

--- 
Pankaj K Garg  [EMAIL PROTECTED]
1684 Nightingale Avenue408-373-4027
Sunnyvale, CA 94304
http://home.earthlink.net/~gargp

--
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: merging mingw and cygwin

At 08:44 PM 10/13/2003, Edward Peschko you wrote:
>> >Fair enough, but you *can* 'pre' approve entrance to the developer's list. 
>> >Remember, you try to subscribe and you get asked four questions?
>> 
>> 
>> You don't need to be on the Cygwin developers list to create patches
>> for Cygwin or play around with the code.  Patches can be submitted either
>> to cygwin-patches (preferred) or this list (not so much but tolerated).
>> You should target cygwin-patches for something like what you're interested
>> in doing.  
>
>that's just odd. ok, well that's just not the way I'm used to doing things.
>On perl5-porters, more than half the discussion is about the merits of 
>patches and the submission of patches. 


That happens at cygwin-patches here.  Different project, different lists.



>And anyways, don't you need to sign some sort of attribution of your source code over
>to the cygwin group? Or is that integrated into cygwin-patches? And what about 
>submissions to folders outside of winsup? Is there a centralized place to submit 
>these?


Time to head back to the documentation.  See 



--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
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: merging mingw and cygwin

> >Fair enough, but you *can* 'pre' approve entrance to the developer's list. 
> >Remember, you try to subscribe and you get asked four questions?
> 
> 
> You don't need to be on the Cygwin developers list to create patches
> for Cygwin or play around with the code.  Patches can be submitted either
> to cygwin-patches (preferred) or this list (not so much but tolerated).
> You should target cygwin-patches for something like what you're interested
> in doing.  

that's just odd. ok, well that's just not the way I'm used to doing things.
On perl5-porters, more than half the discussion is about the merits of 
patches and the submission of patches. 

And anyways, don't you need to sign some sort of attribution of your source code over
to the cygwin group? Or is that integrated into cygwin-patches? And what about 
submissions to folders outside of winsup? Is there a centralized place to submit these?

Ed

--
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/

OT: Re: merging mingw and cygwin

2003-10-13 Thread Paul G.

keeping in mind what someone else said about flame wars...

On 13 Oct 2003 at 15:45, Edward Peschko wrote:

> > Just because they are available does not mean you need to use them!
> > Look I asked you if you were able to build Windows only applications
> > using -mno-cygwin. You failed to answer that question. I'm able to
> > build such apps and you should be too. You are arguing about the
> > differences in implementations and assuming that there will be a
> > problem. Is there a problem for you or not?
> 
> Like I said, I'm not worried about my specific applications. I want
> cygwin to transparently and with no fuss - and correctly - build third
> party APIs, so I can properly link with them (and debug them if
> necessary).
> 
> > We can speculate from now until forever but until and unless you try
> > it you'll never know for sure. Let us know how you make out...
> 
> I did try it. With berkeleydb.  Read my previous post.
> 
> > Not sure what msys is at all...
> 
> msys is the group of tools that comes with mingw32 to facilitate
> building. rm, ln, etc. They work differently than cygwin tools.

Check your information.  As previously noted in another reply to this thread, Msys is 
not Mingw and Mingw is not 
Msys.

Mingw is not included with Msys.  Msys "can use" and "is capable of _recognizing_", 
Mingw.  Msys != Mingw.  Msys 
does not need Mingw to develop anything.

Mingw and Msys are OT for this list.

Paul G.

> 
> > >MINGW and/or NO_CYGWIN simply wrap all of this up in a nice user
> > >friendly package.
> 
> > Let us know how your first implementation of this concept goes...
> 
> Is this an OK from the developers of cygwin to do an implementation,
> with the results of that implementation being merged into cygwin? I
> don't want to spend a lot of time pursuing it if my results don't have
> a chance of being merged.
> 
> The last time I asked, the answer was no to this question.
> 
> Ed
> 
> --
> 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/
> 



--
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: merging mingw and cygwin

At 07:52 PM 10/13/2003, Edward Peschko you wrote:
>> The answer is - the Cygwin team is under no obligation to accept patches
>> to Cygwin to do anything.  Patches are accepted and merged based on merit 
>> of the patch and adherence with Cygwin standards.  If your patch passes 
>> these hurdles, it will be accepted.  If not, it will be rejected (with 
>> comments of course so you may very well be able to address the issues and
>> "resubmit").  No one will pre-approve a concept.  We need to see code.
>> 
>
>Fair enough, but you *can* 'pre' approve entrance to the developer's list. 
>Remember, you try to subscribe and you get asked four questions?


You don't need to be on the Cygwin developers list to create patches
for Cygwin or play around with the code.  Patches can be submitted either
to cygwin-patches (preferred) or this list (not so much but tolerated).
You should target cygwin-patches for something like what you're interested
in doing.  


>Well, I would like the venue to submit patches that way. 


Understood.  But the Cygwin developers list isn't just about patches.
There's really no need for you to be on that list to do what you have
talked about.


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
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: merging mingw and cygwin

2003-10-13 Thread Igor Pechtchanski

On Mon, 13 Oct 2003, Edward Peschko wrote:

> > The answer is - the Cygwin team is under no obligation to accept patches
> > to Cygwin to do anything.  Patches are accepted and merged based on merit
> > of the patch and adherence with Cygwin standards.  If your patch passes
> > these hurdles, it will be accepted.  If not, it will be rejected (with
> > comments of course so you may very well be able to address the issues and
> > "resubmit").  No one will pre-approve a concept.  We need to see code.
> >
>
> Fair enough, but you *can* 'pre' approve entrance to the developer's list.
> Remember, you try to subscribe and you get asked four questions?

Yes.  Simply answer those questions truthfully.  The only one you might
have some reservations about is the "what do you plan to implement" one,
and I haven't heard of anyone being denied subscription on the basis that
what they'd like to implement is not needed (CGF can say for sure).

> Well, I would like the venue to submit patches that way.
> Ed

.  The cygwin-developers
list is not for submitting patches.
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!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

--
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: Error: procedure entry point _getreent could not be located...

2003-10-13 Thread Carlo Florendo

From: "Andrew DeFaria"


> Brian Ford wrote:
>
> >On Mon, 13 Oct 2003, Ravi Malghan wrote:
> >
> >
> >>Hi: I recently added lynx to existing cygwin installation. When
installing Lynx, I noticed it installed a new version of perl. Now when I
try to run perl, I get the error: "procedure entry point _getreent could not
be located in the dynamic link library cygwin1.dll"
> >>
> >>What do I have to do to resolve this. Thanks in advance.
> >>Ravi
> >>
> >>
> >You might try including cygcheck output as directed in
http://cygwin.com/problems.html.
> >
> >My WAG, perl needs Cygwin 1.5.5 and you have 1.3.22 or older.  Did you
update the Cygwin DLL too?
> >
> I do remember somethign about that entrypoint and 1.5.5. However, if
> installing lynx required the new perl and the perl was dependent on
> cygwin1.dll 1.5.5 then shouldn't setup have handled such a dependency
> chain? (Just curious...)

It should've.  Whoever/Whatever is generating the setup.hint file for perl
has been generating *erroneous* setup.hint files.  A workaround is to grab a
previous version known not to break dependencies and install it via setup or
manually.

This behaviour of cygwin perl has been around for several weeks now.

Thanks!

Best Regards,

Carlo
--
Carlo Florendo
Astra Philippines Inc.
http://www.astra.ph

















--
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: merging mingw and cygwin

2003-10-13 Thread Paul G.



On 13 Oct 2003 at 12:00, Edward Peschko wrote:
[snip]
> 
> 
> In other words, depending how you look at it, mingw is defining less
> crucial information, or cygwin is defining more junk. And sometimes
> they define the same stuff differently.
> 
> In any case, the toolsets are incompatible. And this is just the tip
> of the iceberg; If mingw's compiler is doing *anything* different from
> cygwin, and the users of large mingw projects are testing versus
> mingw, then the using of cygwin will result in binaries with annoying,
> hard-to-find bugs.

Umm...that's not exactly true...I think I can speak from experience on this, 
being someone who develops 
using Cygwin (with and w/o -mno-cygwin), Mingw and Msys on a very regular basis 
(maintaining all of those ports for 
two or three, functionally different, APIs).

Paul G.


--
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: merging mingw and cygwin

> The answer is - the Cygwin team is under no obligation to accept patches
> to Cygwin to do anything.  Patches are accepted and merged based on merit 
> of the patch and adherence with Cygwin standards.  If your patch passes 
> these hurdles, it will be accepted.  If not, it will be rejected (with 
> comments of course so you may very well be able to address the issues and
> "resubmit").  No one will pre-approve a concept.  We need to see code.
> 

Fair enough, but you *can* 'pre' approve entrance to the developer's list. 
Remember, you try to subscribe and you get asked four questions?

Well, I would like the venue to submit patches that way. 

Ed

--
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/

Problems with cygwin, "expect" and ssh

2003-10-13 Thread Greenup, Greenup

I've done a fair bit of searching on the net (6+hours of googling), but
can't find a solution, or a complete "No, there's no way to work around
that" to this problem:

   I have to log into a large number of systems, and on some sets (such as
"all devboxes") I like to keep my password the same, for convenience.  (and
to keep my memory sane; I really need to keep this list from going
"hundreds")
   Ssh is my tool of preference, though I could use  telnet.
Unfortunately, the Higher Powers have declared private key authentication
illegal so far (I'm working on them), so I am left with typing this stuff by
hand.
   All of that, I can more or less deal with, until *Password*Day*.
Remember "hundreds"?  Obviously, I don't log into all of these boxes during
a given month, but I really have to be able to get to them when the time
comes.

   Enter "expect", which ships with a little script for changing your
password (even on multiple systems en-mass). Nice.  Except... it doesn't
seem to work with ssh...  Near as I can tell from my googling, a problem of
openssh reading the tty directly, rather than allocating a tty.  True?
False?  What about other things?; messing with the CYGWIN variable, adding
"tty" in there was not helpful, nor was adding "-t" to ssh.  Any other
ideas?  I don't want to use telnet... "console telnet" is nice, and will get
the job done, but it's not a secure answer.
-greenup

--
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: merging mingw and cygwin


On Mon, Oct 13, 2003 at 05:48:47PM -0500, Brian Ford wrote:
> On Mon, 13 Oct 2003, Edward Peschko wrote:
> 
> > And anyways, the version numbers in itself are enough to warrant a
> > merge. Coordinate releases of mingw and cygwin, and the version issues
> > go away.
> >
> Cygwin itself doesn't "coordinate releases".  By that I mean Cygwin,
> w32api, gcc, mingw gcc, etc. are never release together as a package.
> Each is updated on its own schedule.
> 
> If you want a "distribution", and it has been discussed before (see the
> archives), start your own.

and compound the problem by making 3 distinct distributions instead of two?

That isn't solving anything at all.

Ed

--
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: merging mingw and cygwin

At 06:45 PM 10/13/2003, Edward Peschko you wrote:
>> Just because they are available does not mean you need to use them! Look 
>> I asked you if you were able to build Windows only applications using 
>> -mno-cygwin. You failed to answer that question. I'm able to build such 
>> apps and you should be too. You are arguing about the differences in 
>> implementations and assuming that there will be a problem. Is there a 
>> problem for you or not?
>
>Like I said, I'm not worried about my specific applications. I want cygwin
>to transparently and with no fuss - and correctly - build third party APIs,
>so I can properly link with them (and debug them if necessary).
>
>> We can speculate from now until forever but until and unless you try it 
>> you'll never know for sure. Let us know how you make out...
>
>I did try it. With berkeleydb.  Read my previous post.
>
>> Not sure what msys is at all...
>
>msys is the group of tools that comes with mingw32 to facilitate building.
>rm, ln, etc. They work differently than cygwin tools.
>
>> >MINGW and/or NO_CYGWIN simply wrap all of this up in a nice user friendly 
>> >package.
>
>> Let us know how your first implementation of this concept goes...
>
>Is this an OK from the developers of cygwin to do an implementation, with 
>the results of that implementation being merged into cygwin? I don't want 
>to spend a lot of time pursuing it if my results don't have a chance of being
>merged.
>
>The last time I asked, the answer was no to this question.


The answer is - the Cygwin team is under no obligation to accept patches
to Cygwin to do anything.  Patches are accepted and merged based on merit 
of the patch and adherence with Cygwin standards.  If your patch passes 
these hurdles, it will be accepted.  If not, it will be rejected (with 
comments of course so you may very well be able to address the issues and
"resubmit").  No one will pre-approve a concept.  We need to see code.



--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
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: Error: procedure entry point _getreent could not be located...

Brian Ford wrote:

On Mon, 13 Oct 2003, Ravi Malghan wrote:
 

Hi: I recently added lynx to existing cygwin installation. When installing Lynx, I noticed it installed a new version of perl. Now when I try to run perl, I get the error: "procedure entry point _getreent could not be located in the dynamic link library cygwin1.dll"

What do I have to do to resolve this. Thanks in advance.
Ravi
   

You might try including cygcheck output as directed in http://cygwin.com/problems.html.

My WAG, perl needs Cygwin 1.5.5 and you have 1.3.22 or older.  Did you update the Cygwin DLL too?

I do remember somethign about that entrypoint and 1.5.5. However, if 
installing lynx required the new perl and the perl was dependent on 
cygwin1.dll 1.5.5 then shouldn't setup have handled such a dependency 
chain? (Just curious...)
--
When something is "new and improved!". Which is it? If it's new, then 
there has never been anything before it. If it's an improvement, then 
there must have been something before it.



--
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: merging mingw and cygwin

Edward Peschko wrote:

Like I said, I'm not worried about my specific applications. I want cygwin to transparently and with no fuss - and correctly - build third party APIs, so I can properly link with them (and debug them if necessary).

All I can say is what I've heard many others say, which is... PTC.

We can speculate from now until forever but until and unless you try it  you'll never know for sure. Let us know how you make out...
   

I did try it. With berkeleydb.  Read my previous post.

Sorry. I didn't read it thoroughly.

Let us know how your first implementation of this concept goes...
   

Is this an OK from the developers of cygwin to do an implementation, with  the results of that implementation being merged into cygwin? I don't want  to spend a lot of time pursuing it if my results don't have a chance of being merged.

The last time I asked, the answer was no to this question.

Well I'm no developer *OF* Cygwin so I cannot comment with authority 
however if what you say would indeed be useful I'm sure that Cygwin 
people would accept or at least evaluate an implementation that you write.
--
I hit the CTRL key but I'm still not in control!



--
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: results of compiling berkeleydb

At 05:13 PM 10/13/2003, Edward Peschko you wrote:
>On Mon, Oct 13, 2003 at 11:15:25PM +0200, Gerrit P. Haase wrote:
>> Hallo Edward,
>> 
>> >> GCC='gcc -mno-cygwin' ./configure.
>> 
>> [...]
>> 
>> > (ex: -mno-cygwin doesn't define WINNT, which mingw does)
>> 
>> $ gcc -mno-cygwin -dM -E -xc /dev/null  | grep WINNT
>> #define WINNT 1
>
>my mistake. but still, problems exist (as per my previous statement, try the two
>gcc commands one against mingw, the other against cygwin, and compare the two
>results. They are vastly out of sync.


Thanks for the report.  I think it's fair to say that this is a dead thread
unless it inspires someone else to make the changes you want (or you consider
submitting a patch for review that achieves your goals).



--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
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: merging mingw and cygwin

2003-10-13 Thread Lapo Luchini

Brian Ford wrote:

Each is updated on its own schedule.
 

...which can be described as
MAX(upstream release time, next free moment of the volunteer package 
mantainer) + RANDOM(-10, +100)
so it cannot be predicted, either.

It worked fairly well insofar, though.

--
Lapo 'Raist' Luchini
[EMAIL PROTECTED] (PGP & X.509 keys available)
http://www.lapo.it (ICQ UIN: 529796)


--
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: merging mingw and cygwin

2003-10-13 Thread Yitzchak Scott-Thoennes

On Mon, Oct 13, 2003 at 03:20:49PM -0700, Andrew DeFaria <[EMAIL PROTECTED]> wrote:
> Edward Peschko wrote:
> >MINGW and/or NO_CYGWIN simply wrap all of this up in a nice user friendly 
> >package.
> >
> Let us know how your first implementation of this concept goes...

mungewin-0.01?

More seriously, if there are problems with -mno-cygwin building Mingw
ports, perhaps you should report these as bugs.  About Mingw modes for
things other than gcc, I personally don't want the cygwin tools I use
bloated or slowed down by having to have a separate run mode, and I
haven't seen any report of an actual problem that would be solved by
this.

--
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: Possible bug in text/binary mode handling in cygwin1.dll version 1.5

2003-10-13 Thread Vladimir Vysotsky

Rolf Campbell wrote:
C: is not mounted in text mode. /c is mounted in text mode. C: isn't 
mounted at all.
I see your point. However, prior to 1.5 the mount table worked (i.e.,
determined the file mode) even if the path started with "C:", as far as
I understand.
If you set CYGWIN=textmode then that would mean that windows-style
paths would be treated as text-mounts.
Is there a way to specify that _some_ windows-style paths are to be
treated as text-mounts, and others as binary?
Vlad

--
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: merging mingw and cygwin

On Mon, 13 Oct 2003, Edward Peschko wrote:

> And anyways, the version numbers in itself are enough to warrant a
> merge. Coordinate releases of mingw and cygwin, and the version issues
> go away.
>
Cygwin itself doesn't "coordinate releases".  By that I mean Cygwin,
w32api, gcc, mingw gcc, etc. are never release together as a package.
Each is updated on its own schedule.

If you want a "distribution", and it has been discussed before (see the
archives), start your own.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

--
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: Is multithreaded profiling on cygwin possible?

2003-10-13 Thread peter garrone

- Original Message -
From: Brian Ford <[EMAIL PROTECTED]>
Date: Mon, 13 Oct 2003 14:36:34 -0500 (CDT)
To: peter garrone <[EMAIL PROTECTED]>
Subject: Re: Is multithreaded profiling on cygwin possible?

> On Mon, 13 Oct 2003, peter garrone wrote:
> 
> >
> Sounds good, although I'm not quite sure I understand the implementation.
> What you really need to know is what thread was running just before the
> sampling thread so that it can sample the correct thread's PC.  How are
> you using GetThreadTimes for this?

A list of active threads is maintained. A thread calling moncontrol(1) gets
put in the list. When a call to SuspendThread fails, the thread is assumed
to be defunct and taken off the list.

One of the fields in the thread is a counter corresponding to the sum of cpu
returned by GetThreadTimes. This function has fields corresponding to kernel cpu and
user cpu. The amount of time consumed by every thread is saved.

Generally only one thread will have consumed CPU. However to be general,
and in case the profiling thread is inadvertently delayed, all threads are
considered.

There is a partial tick problem. Suppose that a thread has consumed say
155% of the cpu time corresponding to a tick. I would assign one tick
and use a local random number generator to assign an extra tick on average 55% of the 
time.

I tried getting the program counter for all threads, but this was found not to work 
very well,
consuming excessive cpu, on average 50 milliseconds. All the other calls were of
the order of 1 microsecond. However getting the program counter only for any thread
that used cpu according to GetThreadTimes appeared to take about 50 microseconds.
Generally of course only one thread will have used CPU. The function GetThreadContext
is used to obtain the PC. 
> 
> I tried using a backtrace method to map the sampling time onto
> DLL leaf functions (the import stubs) once, but it did not seem possible
> to perfect.  Also, that is not always what you want.

I would be interested if you would expand on this. Do you mean looking at
the stack to find the calling function?

> But, if you want this to be usefull for the community at large, attacking
> the two points in the previous email directly would probably be more
> useful.  ie. Figure out a way to store the samples using a
> non-contiguous address space model, and modify gprof to load the symbol
> tables for the dependent DLLs (gdb does this to some extent).  Note that
> UNIX shared libraries have similar issues.  You may want to consult with
> [EMAIL PROTECTED] for a general solution since they "own" gprof.
> 

I am thinking of implementing a separate profil call so that it can be used
simultaneously with -pg compilation and linking. Also a "profile-dll" call
so that profiling of the space occupied by a dll would occur.

My problem with profiling the entire dll address space is 
1) The necessity of recompiling dll's so that mapping and call counting is implemented
2) The difficulty of doing anything with propriety dll's
3) The size and sparsity of the resulting gmon.out data file.

So I thought I would try attacking the problem using the import libraries.
Perhaps it is a silly idea, but if it could be made to work it avoids these problems.
If I can get it to work, I'll be back.

Thanks
-- 
__
Check out the latest SMS services @ http://www.linuxmail.org 
This allows you to send and receive SMS through your mailbox.

Powered by Outblaze

--
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: merging mingw and cygwin

> Just because they are available does not mean you need to use them! Look 
> I asked you if you were able to build Windows only applications using 
> -mno-cygwin. You failed to answer that question. I'm able to build such 
> apps and you should be too. You are arguing about the differences in 
> implementations and assuming that there will be a problem. Is there a 
> problem for you or not?

Like I said, I'm not worried about my specific applications. I want cygwin
to transparently and with no fuss - and correctly - build third party APIs,
so I can properly link with them (and debug them if necessary).

> We can speculate from now until forever but until and unless you try it 
> you'll never know for sure. Let us know how you make out...

I did try it. With berkeleydb.  Read my previous post.

> Not sure what msys is at all...

msys is the group of tools that comes with mingw32 to facilitate building.
rm, ln, etc. They work differently than cygwin tools.

> >MINGW and/or NO_CYGWIN simply wrap all of this up in a nice user friendly 
> >package.

> Let us know how your first implementation of this concept goes...

Is this an OK from the developers of cygwin to do an implementation, with 
the results of that implementation being merged into cygwin? I don't want 
to spend a lot of time pursuing it if my results don't have a chance of being
merged.

The last time I asked, the answer was no to this question.

Ed

--
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: merging mingw and cygwin

2003-10-13 Thread Lapo Luchini

Edward Peschko wrote:

msys != mingw.  mingw doesn't need msys.  Cygwin provides a more complete
building and testing environment than does msys.
   

... and I was told point blank by the mingw mailing list not to use them.
 

cygwin is a nice user friendly package. I won't speak for mingw because
I have a personal bias.
   

.. so why not bring the nice user friendly experience of cygwin to mingw and let it
piggy back off of cygwin's work?
 

I guess you replied yourself, in the last paragraph...

I know nothing of MingW except what I read on this mailing list and 
their website, but judging fast (and, so, probably wrong), I'd say that 
the very fact that they want to avoid Cygwin like plague (and the choice 
of the word is intentional) *may* have something to with "not bringing 
cygwin user-friendliness to mingw", isn't it?

Lapo, trying not to feed (too much) wood to this MVCFW (Mingw Versus 
Cygwin Flame War ;-)

--
Lapo 'Raist' Luchini
[EMAIL PROTECTED] (PGP & X.509 keys available)
http://www.lapo.it (ICQ UIN: 529796)


--
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: Error: procedure entry point _getreent could not be located...

On Mon, 13 Oct 2003, Ravi Malghan wrote:

> Hi: I recently added lynx to existing cygwin
> installation. When installing Lynx, I noticed it
> installed a new version of perl. Now when I try to run
> perl, I get the error:
> "procedure entry point _getreent could not be located
> in the dynamic link library cygwin1.dll"
>
> What do I have to do to resolve this.
> Thanks in advance.
> Ravi
>
You might try including cygcheck output as directed in
http://cygwin.com/problems.html.

My WAG, perl needs Cygwin 1.5.5 and you have 1.3.22 or older.  Did you
update the Cygwin DLL too?

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

--
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: merging mingw and cygwin

> > As I said, this is just the tip of the iceberg - who knows what patches that
> > mingw has made to gcc, ld, make, etc. which could affect the building and
> > running of large win32 packages.
> 
> I do.  So does Chris, So does anyone who cares to look. The diff for gcc and
> binutils is not an iceberg.

... and textutils, and fileutils, and autogen and shell? and the 100 or so megabytes 
of 
source code?

You forget who I'm defining 'iceberg' for. End users. If *anything* goes wrong in a 
build, for 95% of them, that's it, they are lost. Even for experienced users its still 
a big frustration, tracking down the myriad number of command line parameters in order
to make a compile work. The fact that '-mno-cygwin' works pseudo-correctly 70% of the 
time doesn't make up for the extra 30% where you need to futz around.

And anyways, the version numbers in itself are enough to warrant a merge. Coordinate
releases of mingw and cygwin, and the version issues go away.

> msys != mingw.  mingw doesn't need msys.  Cygwin provides a more complete
> building and testing environment than does msys.

... and I was told point blank by the mingw mailing list not to use them. In fact,
I did try to use them, with not-so-pretty results.

> cygwin is a nice user friendly package. I won't speak for mingw because
> I have a personal bias.

.. so why not bring the nice user friendly experience of cygwin to mingw and let it
piggy back off of cygwin's work?

Ed 

(
   ps - and I'm sorry that you see it as 'harassment'. I seem to remember a 'go away
   RTFM and don't bother us.' response when I first posted. That ain't very friendly
   to start with. If I'm a bit forthright and/or belligerent, I'm sorry but it is in 
   reaction. It does help me make my points clearer though. acceptance may be another
   matter.
)

--
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/

Error: procedure entry point _getreent could not be located...

2003-10-13 Thread Ravi Malghan

Hi: I recently added lynx to existing cygwin
installation. When installing Lynx, I noticed it
installed a new version of perl. Now when I try to run
perl, I get the error:
"procedure entry point _getreent could not be located
in the dynamic link library cygwin1.dll"

What do I have to do to resolve this.
Thanks in advance.
Ravi

__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

--
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: merging mingw and cygwin

Edward Peschko wrote:

touche.. although you could use a mechanism like 'complete' in tcsh to enforce the conversion (complete recognizes things like paths, ip addresses, email addresses, etc.) and enforces conversion by this mechanism. This would work in 95-99% of the cases.

And what of other shells and various other places? Addressing just tcsh
doesn't sound like a very robust solution.

Really? How so? 'Cause I'm still able to use -mno-cygwin and produce Windows only executables. Are you not able to do this? If not then why?

Like I said, try:

mingw > gcc -dM -e -xc /dev/null
cygwin > gcc -mno-cygwin -dM -E -xc /dev/null
cygwin makes 73 defines, mingw makes 38. If a large project uses any of the cygwin defines, it will behave differently than if compiled with native mingw.

Just because they are available does not mean you need to use them! Look
I asked you if you were able to build Windows only applications using
-mno-cygwin. You failed to answer that question. I'm able to build such
apps and you should be too. You are arguing about the differences in
implementations and assuming that there will be a problem. Is there a
problem for you or not?

As I said, this is just the tip of the iceberg - who knows what patches that mingw has made to gcc, ld, make, etc. which could affect the building and running of large win32 packages.

If the large packages built in mingw are tested via mingw, then mingw is the only real way to a 'proper' win32 executable. And the only way to truly emulate mingw32 would be by merging it.

We can speculate from now until forever but until and unless you try it
you'll never know for sure. Let us know how you make out...

Maybe the MingW package in Cygwin needs to be updated, however, I fail to see the need for a MINGW or NO_CYGWIN flavor aside from what currently exists (i.e. -mno-cygwin).

Because gcc is not the only place that has MINGW-isms in it; msys departs from the cygwin standard and handles certain things differently. In order to build MinGW packages right, the underlying tools have to work the same as well.

Not sure what msys is at all...

MINGW and/or NO_CYGWIN simply wrap all of this up in a nice user friendly package.

Let us know how your first implementation of this concept goes...
--
I took an IQ test and the results were negative.

--
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: Can't build cygwin from CVS: configure error

2003-10-13 Thread Hannu E K Nevalainen

> From: Brian Ford
> Sent: Monday, October 13, 2003 8:49 PM

> On Sun, 12 Oct 2003, Hannu E K Nevalainen wrote:
>
> > Sigh - yes, or even better; the FAQ stating that there should
> be a configure
> > script in the root dir after the checkout - as it depends on it beeing
> > there - i.e. "You should now have a /src/configure script. Run it like
> > this:".
> >
> Do you really need that?  Isn't this:

Replied to off list.

 CGF, if you wish to read a reply on your mail; please send an email from a
working address that I can use.
You might not consider it important, but I hope the text I wrote at least
gives some insights.

 The address I use for this list is a fully working one, likely to change
without notice though.

/Hannu E K Nevalainen, B.Sc. EE - 59?16.37'N, 17?12.60'E
-- UTC+01, DST -> UTC+02  --
--END OF MESSAGE--

--
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: merging mingw and cygwin

2003-10-13 Thread Danny Smith

Ed said:

> Like I said, try:
> 
> mingw > gcc -dM -e -xc /dev/null
> cygwin > gcc -mno-cygwin -dM -E -xc /dev/null
> 
> cygwin makes 73 defines, mingw makes 38. If a large project uses any of the
> cygwin defines, it will behave differently than if compiled with native mingw.
> 

That's because you used gcc-3.2.3 with mingw (3.3.1 is still a release
candidate  "over there") and gcc-3.3.1 with cygwin. I agree: A program
compiled with gcc-3.2.3 will be different than one compiled with 3.3.1.

So maybe you should harass the mingw list to update the release status of
gcc.  On second thought, don't do that. I hear they are petty mean over
there, too.

> As I said, this is just the tip of the iceberg - who knows what patches that
> mingw has made to gcc, ld, make, etc. which could affect the building and
> running of large win32 packages.

I do.  So does Chris, So does anyone who cares to look. The diff for gcc and
binutils is not an iceberg.

> 
> If the large packages built in mingw are tested via mingw, then mingw is the
> only real way to a 'proper' win32 executable. And the only way to truly 
> emulate mingw32 would be by merging it.

Wrong.  I can build binutils for mingw with cygwin  gcc -mno-cygwin. It
is the same as the binutils that I build with mingw.  I have built a mingw gcc
with cygwin gcc -mno-cygwin. AFAICT, it is the same as the gcc I build with native
mingw. I don't do it any more because I like to say that I can do a native
bootstrap of gcc for mingw (with the help of cygwin tools)

> 
> > Maybe the MingW package in Cygwin needs to be updated, however, I fail 
> > to see the need for a MINGW or NO_CYGWIN flavor aside from what 
> > currently exists (i.e. -mno-cygwin).
> 
> Because gcc is not the only place that has MINGW-isms in it; msys departs from
> the cygwin standard and handles certain things differently.

msys != mingw.  mingw doesn't need msys.  Cygwin provides a more complete
building and testing environment than does msys.

> In order
> to build MinGW packages right, the underlying tools have to work the same
> as well.
> 
> MINGW and/or NO_CYGWIN simply wrap all of this up in a nice user friendly
> package.

cygwin is a nice user friendly package. I won't speak for mingw because
I have a personal bias.

Danny

> 
> Ed
> 

http://search.yahoo.com.au - Yahoo! Search
- Looking for more? Try the new Yahoo! Search

--
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: gcc -dM -E -xc /dev/null & g++ -dM -E -xc /dev/null

2003-10-13 Thread Ross Smith

Rick Rankin wrote:
--- Christopher Faylor <[EMAIL PROTECTED]> wrote:

On Mon, Oct 13, 2003 at 07:22:28AM +0200, Alex Vinokur wrote:

gcc -dM -E -xc /dev/null
and
g++ -dM -E -xc /dev/null
produce the same output.
Is this a feature or a bug?
It is not a bug.  Try it on linux.


How can one know that g++ (not gcc) is invoked?
Isn't the __cplusplus define a feature of c++?  I'm too lazy to check if this
is a g++ extension but I'd be surprised if it was.
Yes, it's defined in section 16.8 (Predefined macro names) of the ANSI/ISO
standard.
The original poster was using the -xc flag, which tells the compiler
that the following source file is to be read as C regardless of the
file name. I'd expect exactly the same preprocessor output from both
frontends in that case.
--
Ross Smith .. Pharos Systems, Auckland, New Zealand
"I virtually never go out of the house with less computing
power on my person than the entire North American continent
circa 1973." -- Charlie Stross


--
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 window size

2003-10-13 Thread yoram


Hi,
I wish that the max size of my cygwin window will be full screen.
currently it is only 3/4 screen.

I do'nt want to use the X - xterm for this purpose because it slows the computer.

Is there a way to config the max cygwin window size ?

ThankX 



--
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: merging mingw and cygwin

> >well, I'd expect to see the mingw application choke if I ran it through 
> >cmd.exe this way..
> >
> >I don't see why it would have to choke if it ran through *SH.EXE* this 
> >way. sh.exe - in either the mingw32 world or the the cygwin world - could 
> >handle the arguments. And that way, interoperate a lot better with Win32.
> >
> How (and why) should sh.exe convert anything for the program it's about 
> to exec? To do that it would have to be cognizant that this is a MingW 
> executable and therefore needs conversion of such things as pathnames. 
> How would it know that the underlying executable did not want 
> "Date/Time" as a string as opposed to some sort of filename? The shell 
> shouldn't been guessing and converting things like this because it just 
> doesn't know enough to guess right.

touche.. although you could use a mechanism like 'complete' in tcsh to 
enforce the conversion (complete recognizes things like paths, ip addresses,
email addresses, etc.) and enforces conversion by this mechanism. This would 
work in 95-99% of the cases.

> Really? How so? 'Cause I'm still able to use -mno-cygwin and produce 
> Windows only executables. Are you not able to do this? If not then why?

Like I said, try:

mingw > gcc -dM -e -xc /dev/null
cygwin > gcc -mno-cygwin -dM -E -xc /dev/null

cygwin makes 73 defines, mingw makes 38. If a large project uses any of the
cygwin defines, it will behave differently than if compiled with native mingw.

As I said, this is just the tip of the iceberg - who knows what patches that
mingw has made to gcc, ld, make, etc. which could affect the building and
running of large win32 packages. 

If the large packages built in mingw are tested via mingw, then mingw is the
only real way to a 'proper' win32 executable. And the only way to truly 
emulate mingw32 would be by merging it.

> Maybe the MingW package in Cygwin needs to be updated, however, I fail 
> to see the need for a MINGW or NO_CYGWIN flavor aside from what 
> currently exists (i.e. -mno-cygwin).

Because gcc is not the only place that has MINGW-isms in it; msys departs from
the cygwin standard and handles certain things differently. In order
to build MinGW packages right, the underlying tools have to work the same
as well.

MINGW and/or NO_CYGWIN simply wrap all of this up in a nice user friendly
package.

Ed

--
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: merging mingw and cygwin

2003-10-13 Thread Robert McNulty Junior

Ed, mingw is a bunch of library files used with Mingw.
I notice, though, that I can create a Windows based GUI with the mingw
and w32api from Sourceforge better than I could with Cygwin.
When I want a Unix program compiled, I turn to Cygwin.
I also have Visual Studio, but it ain't great for Cygwin or Mingw.
Earnie Boyd just came out with a new Mingw runtime. Works better and
better all the time.
Enough out of me as this is off-topic and hush-hush.
Robert McNulty Junior

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Edward Peschko
Sent: Monday, October 13, 2003 3:35 PM
To: Andrew DeFaria
Cc: [EMAIL PROTECTED]
Subject: Re: merging mingw and cygwin

> I, like others, think that you are just looking at this sideways. If I

> compile a program with MingW it is to produce a Windows only
executable 
> totally unaware of Cygwin, Posix or anything. The only thing I'd
expect 
> it to "understand" is Windows conventions. As such I'd expect that 
> program to only honor Windows compilant pathnames and if it did see a 
> /path/to/file I'd expect it to choke - wouldn't you?

well, I'd expect to see the mingw application choke if I ran it through
cmd.exe 
this way..

I don't see why it would have to choke if it ran through *SH.EXE* this
way.
sh.exe - in either the mingw32 world or the the cygwin world - could
handle
the arguments. And that way, interoperate a lot better with Win32.

And I don't care if cygwin sh.exe links with cyg*.dll. The whole point
of this 
is to make the final product - be it end-user application or third party
API - 
be able to not use the cygwin1.dll if it doesn't want to. I set MINGW ==
1 or 
NO_CYGWIN == 1, use cyg*.dll to do the development, and my final
executable is 
true, blue mingw32.

In fact, that's the whole point behind -mno-cygwin. 
Witness http://www.delorie.com/howto/cygwin/mno-cygwin-howto.html:

"The reason behind implementing the -mno-cygwin option is quite simple:
since you
already have the Cygwin development tools loaded, wouldn't it be nice
to be able to create Mingw executables using the same compiler and tools
instead
of having to load yet another set of Mingw-specific development tools?"

Its my contention that -mno-cygwin is fundamentally broken; and to make
it truly
work cygwin needs to incorporate the mingw32 patches and the tools have
to take
the 'flavor' of mingw32 when MINGW is set or NO_CYGWIN is set. My
ultimate goal
would be to build everything from scratch

> You seem to want something in the middle (which is understandable but 
> which, AFAICT, doesn't exist). You want to be able to use a Unix-like 
> environment and code Unix-like symantics yet produce a pure Windows 
> executable (i.e. MS C Runtime) and then you want some *magic* to 
> translate such Posix assumptions into "Windowese".  

As I said before, that "magic" would be nice to use whilst developing..
I don't
need the magic in my final executable. In some cases its a nice thing to
have
(ie: cross-platform unix/win32) but it need not be there all the time.
Its a 
hindrance, not a help to force it there.

> The only way I think you can truly accomplish what you want is to 
> effectively do all the work that Cygwin has already done, by hand, 
> recoding it so as not to be stealing, and release your runtime license

> free or on the "Artist" license like Perl. You'd still have the 
> dependency and your target machines would need this "magic" dll but 
> you'd be freed from the licensing requirements.

or, basically take all the patches that mingw32 has done, and
reintegrate them
into cygwin under a MINGW or NO_CYGWIN flavor.

Ed

--
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/




--
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: Possible bug in text/binary mode handling in cygwin1.dll version 1.5

2003-10-13 Thread Rolf Campbell

Vladimir Vysotsky wrote:
Hi,

I'm using the following sequence of actions to reproduce this problem:


C:\test>bash
bash-2.05b$ echo "Test" >/c/test/test1.txt
bash-2.05b$ echo "Test" >c:/test/test2.txt
bash-2.05b$ ls -l
total 2
-rw-r--r--1 vvysotsk mkpasswd6 Oct 10 19:49 test1.txt
-rw-r--r--1 vvysotsk mkpasswd6 Oct 10 19:49 test2.txt
bash-2.05b$

Since drive C: is mounted in text mode (mount -f -s -t "c:" /c), both 
test1.txt and test2.txt are 6 bytes long ('T', 'e', 's', 't', 0x0D, 
0x0A). This is with cygwin1.dll version 1.3.2.

However, when I install cygwin1.dll version 1.5.x, test2.txt is only
5 bytes long, ending with just 0x0A:
C: is not mounted in text mode.  /c is mounted in text mode.  C: isn't 
mounted at all.

If you set CYGWIN=textmode then that would mean that windows-style paths 
would be treated as text-mounts.



--
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: results of compiling berkeleydb

On Mon, Oct 13, 2003 at 11:15:25PM +0200, Gerrit P. Haase wrote:
> Hallo Edward,
> 
> >> GCC='gcc -mno-cygwin' ./configure.
> 
> [...]
> 
> > (ex: -mno-cygwin doesn't define WINNT, which mingw does)
> 
> $ gcc -mno-cygwin -dM -E -xc /dev/null  | grep WINNT
> #define WINNT 1

my mistake. but still, problems exist (as per my previous statement, try the two
gcc commands one against mingw, the other against cygwin, and compare the two
results. They are vastly out of sync.

Ed

--
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: results of compiling berkeleydb

2003-10-13 Thread Gerrit P. Haase

Hallo Edward,

>> GCC='gcc -mno-cygwin' ./configure.

[...]

> (ex: -mno-cygwin doesn't define WINNT, which mingw does)

$ gcc -mno-cygwin -dM -E -xc /dev/null  | grep WINNT
#define WINNT 1

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/

Re: merging mingw and cygwin

Edward Peschko wrote:

I, like others, think that you are just looking at this sideways. If I compile a program with MingW it is to produce a Windows only executable totally unaware of Cygwin, Posix or anything. The only thing I'd expect it to "understand" is Windows conventions. As such I'd expect that program to only honor Windows compilant pathnames and if it did see a /path/to/file I'd expect it to choke - wouldn't you?

well, I'd expect to see the mingw application choke if I ran it through cmd.exe this way..

I don't see why it would have to choke if it ran through *SH.EXE* this way. sh.exe - in either the mingw32 world or the the cygwin world - could handle the arguments. And that way, interoperate a lot better with Win32.

How (and why) should sh.exe convert anything for the program it's about
to exec? To do that it would have to be cognizant that this is a MingW
executable and therefore needs conversion of such things as pathnames.
How would it know that the underlying executable did not want
"Date/Time" as a string as opposed to some sort of filename? The shell
shouldn't been guessing and converting things like this because it just
doesn't know enough to guess right.

And I don't care if cygwin sh.exe links with cyg*.dll. The whole point of this is to make the final product - be it end-user application or third party API - be able to not use the cygwin1.dll if it doesn't want to. I set MINGW == 1 or NO_CYGWIN == 1, use cyg*.dll to do the development, and my final executable is
true, blue mingw32.

In fact, that's the whole point behind -mno-cygwin. Witness http://www.delorie.com/howto/cygwin/mno-cygwin-howto.html:

"The reason behind implementing the -mno-cygwin option is quite simple: since you already have the Cygwin development tools loaded, wouldn't it be nice to be able to create Mingw executables using the same compiler and tools instead of having to load yet another set of Mingw-specific development tools?"

Its my contention that -mno-cygwin is fundamentally broken;

Really? How so? 'Cause I'm still able to use -mno-cygwin and produce
Windows only executables. Are you not able to do this? If not then why?

and to make it truly work cygwin needs to incorporate the mingw32 patches and the
tools have to take
the 'flavor' of mingw32 when MINGW is set or NO_CYGWIN is set. My ultimate goal would
be to build everything from scratch
Are you just saying that the version of MingW in Cygwin is old and needs
to be patched to come up to date?

As I said before, that "magic" would be nice to use whilst developing..

Seems to me you have this capability already under Cygwin.

I don't need the magic in my final executable.

Seems to me you have this capability after you produce your final
executable with -mno-cygwin. If so then I fail to see what your
"problem" is.

In some cases its a nice thing to have (ie: cross-platform unix/win32) but it need not be there all the time. Its a hindrance, not a help to force it there.

The only way I think you can truly accomplish what you want is to effectively do all the work that Cygwin has already done, by hand, recoding it so as not to be stealing, and release your runtime license free or on the "Artist" license like Perl. You'd still have the dependency and your target machines would need this "magic" dll but you'd be freed from the licensing requirements.

or, basically take all the patches that mingw32 has done, and reintegrate them into cygwin under a MINGW or NO_CYGWIN flavor.

Maybe the MingW package in Cygwin needs to be updated, however, I fail
to see the need for a MINGW or NO_CYGWIN flavor aside from what
currently exists (i.e. -mno-cygwin).
--
Will the information superhighway have any rest stops?

--
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: merging mingw and cygwin

> I, like others, think that you are just looking at this sideways. If I 
> compile a program with MingW it is to produce a Windows only executable 
> totally unaware of Cygwin, Posix or anything. The only thing I'd expect 
> it to "understand" is Windows conventions. As such I'd expect that 
> program to only honor Windows compilant pathnames and if it did see a 
> /path/to/file I'd expect it to choke - wouldn't you?

well, I'd expect to see the mingw application choke if I ran it through cmd.exe 
this way..

I don't see why it would have to choke if it ran through *SH.EXE* this way.
sh.exe - in either the mingw32 world or the the cygwin world - could handle
the arguments. And that way, interoperate a lot better with Win32.

And I don't care if cygwin sh.exe links with cyg*.dll. The whole point of this 
is to make the final product - be it end-user application or third party API - 
be able to not use the cygwin1.dll if it doesn't want to. I set MINGW == 1 or 
NO_CYGWIN == 1, use cyg*.dll to do the development, and my final executable is 
true, blue mingw32.

In fact, that's the whole point behind -mno-cygwin. 
Witness http://www.delorie.com/howto/cygwin/mno-cygwin-howto.html:

"The reason behind implementing the -mno-cygwin option is quite simple: since you
already have the Cygwin development tools loaded, wouldn't it be nice
to be able to create Mingw executables using the same compiler and tools instead
of having to load yet another set of Mingw-specific development tools?"

Its my contention that -mno-cygwin is fundamentally broken; and to make it truly
work cygwin needs to incorporate the mingw32 patches and the tools have to take
the 'flavor' of mingw32 when MINGW is set or NO_CYGWIN is set. My ultimate goal
would be to build everything from scratch

> You seem to want something in the middle (which is understandable but 
> which, AFAICT, doesn't exist). You want to be able to use a Unix-like 
> environment and code Unix-like symantics yet produce a pure Windows 
> executable (i.e. MS C Runtime) and then you want some *magic* to 
> translate such Posix assumptions into "Windowese".  

As I said before, that "magic" would be nice to use whilst developing.. I don't
need the magic in my final executable. In some cases its a nice thing to have
(ie: cross-platform unix/win32) but it need not be there all the time. Its a 
hindrance, not a help to force it there.

> The only way I think you can truly accomplish what you want is to 
> effectively do all the work that Cygwin has already done, by hand, 
> recoding it so as not to be stealing, and release your runtime license 
> free or on the "Artist" license like Perl. You'd still have the 
> dependency and your target machines would need this "magic" dll but 
> you'd be freed from the licensing requirements.

or, basically take all the patches that mingw32 has done, and reintegrate them
into cygwin under a MINGW or NO_CYGWIN flavor.

Ed

--
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/

Fw: Setup Hangs in XFree86-bin-icons.sh

2003-10-13 Thread Cliff Hones

This was posted to me privately (possibly by mistake).  Looks
as though it could help with the setup hanging investigation.
[It's been quite a day for replying to sender instead of list.]

-- Cliff

chris <[EMAIL PROTECTED]> wrote:
> I've got to pop off now, but I thought I would express some inital 
> experiments...
> 
> The problem doesn't seem to be specifically relating to cygpath.exe. I 
> get the same problem with the program I list at the end of the email. 
> The problem goes away if I remove the function dowin (note that I never 
> actually call the program, I just exit immediatly)
> 
> I shall try to continue to cut down my minimal case later, but I thought 
> this added an interesting twist to the problem :)
> 
> 
> -- Program follows --
> 
> #define NOCOMATTRIBUTE
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> 
> static int allusers_flag;
> 
> static void
> dowin (char option)
> {
>   char *buf;
>   DWORD len = MAX_PATH;
>   WIN32_FIND_DATA w32_fd;
>   LPITEMIDLIST id;
>   HINSTANCE k32;
>   BOOL (*GetProfilesDirectoryAPtr) (LPSTR, LPDWORD) = 0;
> 
>  
>   SHGetSpecialFolderLocation (NULL, allusers_flag ?
> CSIDL_COMMON_PROGRAMS : CSIDL_PROGRAMS, &id);
>   SHGetPathFromIDList (id, buf);
>   /* This if clause is a Fix for Win95 without any "All Users" */
>   if (strlen (buf) == 0)
> {
>   SHGetSpecialFolderLocation (NULL, CSIDL_PROGRAMS, &id);
>   SHGetPathFromIDList (id, buf);
> }
> }
> 
> 
> 
> int
> main (int argc, char **argv)
> {
>   int c, o = 0;
>   int options_from_file_flag;
>   char *filename;
>   return 0;}
> 
> 
> 

--
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: merging mingw and cygwin

On Mon, 13 Oct 2003, Andrew DeFaria wrote:

> The only way I think you can truly accomplish what you want is to
> effectively do all the work that Cygwin has already done, by hand,
> recoding it so as not to be stealing, and release your runtime license
> free or on the "Artist" license like Perl. You'd still have the
> dependency and your target machines would need this "magic" dll but
> you'd be freed from the licensing requirements.
>
> Good luck! Let us know when you're finished with the project! :-)
>
I think it was called PW32, and AFAICS, it'd dead. :)

http://pw32.sourceforge.net/

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

--
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: merging mingw and cygwin

Edward Peschko wrote:

Have you tried to compile an application using -mno-cygwin? Have you tried to run the resulting executable? I have. I created an application using -mno-cygwin and to my surprise it became "Windows" like in that thinks like pathnames had to be specified in Window'ese. So before, in
the Cygwin environment I could:

yes, I've tried that, and yes, it points out the redudancy of the two projects. My point(s) are:

a) that it is not a good fit. It does a 'good job'
b) its a big usability issue.
[snip]

$ myapp /path/to/file

but now, after -mno-cygwin I must:

$ myapp C:\\path\\to\\file

That's what I really don't understand about cygwin and mingw32, both. Why can't they make a mutual convention: to take things of the form /path/to/file and change them to C:/cygwin/path/to/file, things of the form /cygdrive/c/path/to/file and make this C:/path/to/file, and always use the internal form 'C:/path/to/file' to open files?

ie - if programs are running under sh.exe, massage at the *shell* level, not let individual applications manage their arguments.

I, like others, think that you are just looking at this sideways. If I
compile a program with MingW it is to produce a Windows only executable
totally unaware of Cygwin, Posix or anything. The only thing I'd expect
it to "understand" is Windows conventions. As such I'd expect that
program to only honor Windows compilant pathnames and if it did see a
/path/to/file I'd expect it to choke - wouldn't you?

If I wanted my application to work with Unix'isms and Posix'isms then it
must rely on an emulation layer since Windows at it's core (i.e. the MS
C Runtime) does not do Unix or Posix very well (if at all). So then I
create a Cygwin reliant application (i.e. use Cygwin's runtime emulation
layer - cygwin1.dll) and my consumers would need to install Cygwin.

You seem to want something in the middle (which is understandable but
which, AFAICT, doesn't exist). You want to be able to use a Unix-like
environment and code Unix-like symantics yet produce a pure Windows
executable (i.e. MS C Runtime) and then you want some *magic* to
translate such Posix assumptions into "Windowese". Well that "magic"
has been done before. It is called cygwin1.dll and surprise if you glue
that magic into your "Windows only" application it becomes a non
"Windows only" application with a reliance on cygwin1.dll. So your back
in the same boat needing to get Cygwin's cygwin1.dll on your target
machines and wham you come right smack up against the GPL.

The only way I think you can truly accomplish what you want is to
effectively do all the work that Cygwin has already done, by hand,
recoding it so as not to be stealing, and release your runtime license
free or on the "Artist" license like Perl. You'd still have the
dependency and your target machines would need this "magic" dll but
you'd be freed from the licensing requirements.

Good luck! Let us know when you're finished with the project! :-)
--
If lawyers are disbarred and clergymen defrocked, doesn't it follow that
electricians can be delighted, musicians denoted, cowboys deranged,
models deposed, tree surgeons debarked, and dry cleaners depressed?

--
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: tcflush hang problem

Sorry, my fingers aren't working.  I keep accidentally replying to the
sender rather than/in addition to the list.

Cygwin's current tcflush implimentation is rather crude.  Although, it may
not be possible to do any better.  PTC.

  if (queue == TCIFLUSH || queue == TCIOFLUSH)
/* Input flushing by polling until nothing turns up
   (we stop after 1000 chars anyway) */
for (int max = 1000; max > 0; max--)
  {
COMSTAT st;
if (!PurgeComm (get_handle (), PURGE_RXABORT | PURGE_RXCLEAR))
  break;
low_priority_sleep (100);
if (!ClearCommError (get_handle (), &ev, &st) || !st.cbInQue)
  break;
  }

So, your not really hung.  Just stuck for a long time.

As a work around, tell the device to shut up first, then flush.

On Mon, 13 Oct 2003, Martin Farnik wrote:

> Hi.
> I use CYGWIN_98-4.10 mine 1.5.5(0.94/3/2) 2003-09-20 16:31 i686 uknown
> unknown Cygwin
>
> First i try to describe a situation:
> I have a device which is connected with computer thru serial line.
> Device is still sending data.These data isn't for my program.I have
> open com port and let them go into buffer . When a want to talk with
> device i flush input buffer, send it a command paket and device stop
> sending data and wait for my next command.
> Problem is when I want to flush INPUT buffer before I send a command. In
> this point it hangs, maybe for buffer full.
> Here is piece of code:
>
> -I open port when i start program -
>
>  fd = open(PORT0, O_RDWR | O_NOCTTY );
>  tcgetattr(fd,&oldtio); /* save current port settings */
>
> bzero(&newtio, sizeof(newtio));
> newtio.c_cflag = CS8 | CLOCAL | CREAD | CSTOPB;
> newtio.c_iflag = 0;
> newtio.c_oflag &= ~OPOST;
> newtio.c_lflag = 0;
>
> newtio.c_cc[VTIME]= 1;
> newtio.c_cc[VMIN] = 0;
>
>   cfsetispeed(&newtio,B19200);
>   cfsetospeed(&newtio,B19200);
> tcflush(fd, TCIFLUSH);
> tcsetattr(fd,TCSANOW,&newtio);
> -
> --this code is execute when a want to talk with device
>
>tcflush(fd, TCIFLUSH); <- in this point where it hangs
>   err = write (fd,iobuffer,10);
>

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

--
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: Is multithreaded profiling on cygwin possible?

On Mon, 13 Oct 2003, peter garrone wrote:

> As you have suggested, I have tried setting up a list of
> threads in profil.c, calling SuspendThread,
> GetThreadTimes, to get timing information for all threads,
> and to create a reasonably accurate profile for non-dll user space
> using gprof.
>
Sounds good, although I'm not quite sure I understand the implementation.
What you really need to know is what thread was running just before the
sampling thread so that it can sample the correct thread's PC.  How are
you using GetThreadTimes for this?

> My plan now is to create new dll import libraries so that when these
> dll functions are called, a flag is set in the thread structure list,
> and the profiling thread assigns cpu ticks against the statically linked
> small import functions, so that hopefully gprof will pick it up and
> assign some sort of cpu usage and call frequency count to all the
> functions in the import libraries.
>
> If you can see any obvious pitfalls with this approach, I would be grateful.
>
Using a flag in a structure list sounds like you're asking for race
conditions with threads.

I tried using a backtrace method to map the sampling time onto
DLL leaf functions (the import stubs) once, but it did not seem possible
to perfect.  Also, that is not always what you want.

I don't have any good suggestions or pitfalls to point out.

But, if you want this to be usefull for the community at large, attacking
the two points in the previous email directly would probably be more
useful.  ie. Figure out a way to store the samples using a
non-contiguous address space model, and modify gprof to load the symbol
tables for the dependent DLLs (gdb does this to some extent).  Note that
UNIX shared libraries have similar issues.  You may want to consult with
[EMAIL PROTECTED] for a general solution since they "own" gprof.

If you're just doing this for your own use, go for it.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

--
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: merging mingw and cygwin

> Have you tried to compile an application using -mno-cygwin? Have you 
> tried to run the resulting executable? I have. I created an application 
> using -mno-cygwin and to my surprise it became "Windows" like in that 
> thinks like pathnames had to be specified in Window'ese. So before, in 
> the Cygwin environment I could:

yes, I've tried that, and yes, it points out the redudancy of the two projects.
My point(s) are:

a) that it is not a good fit. It does a 'good job'
b) its a big usability issue.

For example, see 'results of compiling berkeleydb'. cross-compilation in general
is a big pain, and its hard to do right. Not to repeat what I said there, but simply
do the following experiment:

mingw > gcc -dM -e -xc /dev/null

and you get:

 mingw 
#define _WIN32 1
#define _X86_ 1
#define __HAVE_BUILTIN_SETJMP__ 1
#define __i386__ 1
#define __SIZE_TYPE__ unsigned int
#define __GNUC_PATCHLEVEL__ 3
#define _stdcall __attribute__((__stdcall__))
#define __MSVCRT__ 1
#define __USER_LABEL_PREFIX__ _
#define __tune_pentium__ 1
#define __STDC_HOSTED__ 1
#define __WIN32 1
#define __stdcall __attribute__((__stdcall__))
#define __WCHAR_TYPE__ short unsigned int
#define __MINGW32__ 1
#define WIN32 1
#define __WINT_TYPE__ short unsigned int
#define __GNUC__ 3
#define _cdecl __attribute__((__cdecl__))
#define __tune_i586__ 1
#define __WINNT 1
#define __WINNT__ 1
#define __fastcall __attribute__((__fastcall__))
#define _fastcall __attribute__((__fastcall__))
#define __USING_SJLJ_EXCEPTIONS__ 1
#define __WIN32__ 1
#define WINNT 1
#define __GXX_ABI_VERSION 102
#define i386 1
#define __GNUC_MINOR__ 2
#define __STDC__ 1
#define __PTRDIFF_TYPE__ int
#define __REGISTER_PREFIX__ 
#define __cdecl __attribute__((__cdecl__))
#define __NO_INLINE__ 1
#define __i386 1
#define __VERSION__ "3.2.3 (mingw special 20030504-1)"
#define __declspec(x) __attribute__((x))
 mingw 

cygwin > gcc -mno-cygwin -dM -e -xc /dev/null


 cygwin  
#define __DBL_MIN_EXP__ (-1021)
#define __FLT_MIN__ 1.17549435e-38F
#define _WIN32 1
#define _X86_ 1
#define __CHAR_BIT__ 8
#define __WCHAR_MAX__ 65535U
#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
#define __FLT_EVAL_METHOD__ 2
#define __i386__ 1
#define __SIZE_TYPE__ unsigned int
#define __DBL_MIN_10_EXP__ (-307)
#define __FINITE_MATH_ONLY__ 0
#define __GNUC_PATCHLEVEL__ 1
#define __FLT_RADIX__ 2
#define __LDBL_EPSILON__ 1.08420217248550443401e-19L
#define _stdcall __attribute__((__stdcall__))
#define __SHRT_MAX__ 32767
#define __LDBL_MAX__ 1.18973149535723176502e+4932L
#define __MSVCRT__ 1
#define __LDBL_MAX_EXP__ 16384
#define __LONG_MAX__ 2147483647L
#define __SCHAR_MAX__ 127
#define __DBL_DIG__ 15
#define __USER_LABEL_PREFIX__ _
#define __STDC_HOSTED__ 1
#define __WIN32 1
#define __stdcall __attribute__((__stdcall__))
#define __LDBL_MANT_DIG__ 64
#define __FLT_EPSILON__ 1.19209290e-7F
#define __tune_i686__ 1
#define __LDBL_MIN__ 3.36210314311209350626e-4932L
#define __WCHAR_TYPE__ short unsigned int
#define __MINGW32__ 1
#define __FLT_DIG__ 6
#define __FLT_MAX_10_EXP__ 38
#define __INT_MAX__ 2147483647
#define WIN32 1
#define __FLT_MAX_EXP__ 128
#define __DECIMAL_DIG__ 21
#define __DBL_MANT_DIG__ 53
#define __WINT_TYPE__ unsigned int
#define __GNUC__ 3
#define _cdecl __attribute__((__cdecl__))
#define __LDBL_MIN_EXP__ (-16381)
#define __LDBL_MAX_10_EXP__ 4932
#define __DBL_EPSILON__ 2.2204460492503131e-16
#define __DBL_MAX__ 1.7976931348623157e+308
#define __tune_pentiumpro__ 1
#define __fastcall __attribute__((__fastcall__))
#define _fastcall __attribute__((__fastcall__))
#define __USING_SJLJ_EXCEPTIONS__ 1
#define __DBL_MAX_EXP__ 1024
#define __WIN32__ 1
#define WINNT 1
#define __FLT_DENORM_MIN__ 1.40129846e-45F
#define __LONG_LONG_MAX__ 9223372036854775807LL
#define __FLT_MAX__ 3.40282347e+38F
#define __GXX_ABI_VERSION 102
#define __FLT_MIN_10_EXP__ (-37)
#define __FLT_MIN_EXP__ (-125)
#define i386 1
#define __GNUC_MINOR__ 3
#define __DBL_MAX_10_EXP__ 308
#define __LDBL_DENORM_MIN__ 3.64519953188247460253e-4951L
#define __DBL_MIN__ 2.2250738585072014e-308
#define __PTRDIFF_TYPE__ int
#define __LDBL_MIN_10_EXP__ (-4931)
#define __REGISTER_PREFIX__ 
#define __cdecl __attribute__((__cdecl__))
#define __LDBL_DIG__ 18
#define __NO_INLINE__ 1
#define __i386 1
#define __FLT_MANT_DIG__ 24
#define __VERSION__ "3.3.1 (cygming special)"
#define __declspec(x) __attribute__((x))
 cygwin  


In other words, depending how you look at it, mingw is defining less crucial 
information, or cygwin is defining more junk. And sometimes they define
the same stuff differently.

In any case, the toolsets are incompatible. And this is just the tip 
of the iceberg; If mingw's compiler is doing *anything* different from 
cygwin, and the users of large mingw projects are testing versus mingw, then
the using of cygwin will result in binaries with annoying, hard-to-find bugs.

Ed

> 
> $ myapp /path/to/file
> 
> but now, after -mno-cygwin I must:
> 
> $ myapp C:\\path\\to\\file

RE: Can't build cygwin from CVS: configure error

On Sun, 12 Oct 2003, Hannu E K Nevalainen wrote:

> Sigh - yes, or even better; the FAQ stating that there should be a configure
> script in the root dir after the checkout - as it depends on it beeing
> there - i.e. "You should now have a /src/configure script. Run it like
> this:".
>
Do you really need that?  Isn't this:

/src/configure --prefix=/install -v > configure.log 2>&1

sufficient to imply its existance?

>  (The description also assumes that one have done "cd /"... but it isn't
> stated anywhere... confusion factor increases.)

cd /obj

was the line directly above the former one quoted.

> That would have made me - being a beginner - able to tell that something was
> wrong, not considering cvs malfunction at this occasion.
>
>  As a beginner I'm vulnerable to things like that - I do not have the
> experience to say when something has gone wrong.
> I would consider this being "a stability issue" for the FAQ/documentation.
> Software that is "unstable" usually gets fixed... hint, hint ;-)
> (yes I know; PTC, we've been there before)
>
Well, it is generally considered that anyone trying to build and debug
Cygwin should be reasonably familiar with these standard software
development tools.  No offense intended, but this is the Cygwin FAQ, not
the CVS, GNU configure, etc. FAQ.

> > >I'll be investigating gdb and the possibilities with this dll.
> >
> > CGF: Please don't bother.  I'm asking again.  Please give it up.
>
>  Right, I've got the picture... I have interest in the matter though, this
> is the way I learn.
>
There is nothing wrong with trying to learn.  Just realize that when you
are a complete newbie to the entire environment surrounding the project,
you probably have more basic questions than the community at large.  As
such, a documentation clarification is not always the appropriate action.
Sometimes, minimal user education is sufficient.

> Once again, I'm not *trying* to get you into this mood. My style of
> expressing myself, my frustration and such, seems to peck hard on your mind.
> Sorry about that. I wish I could supply you with "polariod glasses" for
> filtering it out.
>
If it is any consolation, cgf and I had a pretty big "run in" when I
started on this list too.  At least when talking directly to him or making
bug reports, try to put on those "polariod glasses" while you type.  :)

It is easy to take a problem report in a "whiny" tone as insulting when
you are a developer who donates most of your time.  Just try to stick with
the facts.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

--
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: compile and dynamic linking in one commandline

2003-10-13 Thread Vaillant Etienne

Hi,

Hi all,

Is it possible to compile and link a source file with a dll to an
executable in one step? 

At this moment I use 2 steps:
g++ -c -I"../include" -o"../../Objects/Main.o" Main.cpp
g++ -o"../../Target/Main.exe ../../Objects/Main.o
../../Target/libObject.dll
It is possible :

g++ -I"../include" -o"../../Target/Main.exe" Main.cpp -lObject 
-L"../../Target/"

Etienne



--
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: Can't build cygwin from CVS: configure error

On Sat, 11 Oct 2003, Micha Nelissen wrote:

> Nelissen, M. wrote:
>
> > This is exactly the same as mine! (Without the --enable-debug). So my
> > configure script itself is broken? Could it be my version of
> > autoconf/automake or outdated or broken?
>
> This was indeed the case. I ran cygwin setup again and did some messing
> with automake/autoconf. I turned out I had: autoconf, autoconf-devel,
> autoconf-stable. Same for automake. I then removed autoconf and
> reinstalled autoconf-stable. Again same for automake. Then all was built
> succesfully.
>
> - Why are there 3 packages anyway?
>
There were major incompatible changes from the long lived autoconf
version 2.13 to the current version 2.57a.  Likewise for automake
versuib 1.4-p5 to automake version 1.7.5a.  Many projects have yet to
convert to the new versions.  As such, Cygwin's autoconf/automake
maintainer was nice enough to provide both with wrapper scripts (the
plain automake and autoconf packages) that try to pick the "right" versions.

> - Why is it autoconf, autoconf-stable and not autoconf-unstable, autoconf?
>
See above.

As for your compile issues that were resolved by a re-install, I don't
know.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

--
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/

Zpravodaj digi fotografie c. 41 (10.10.2003); posledni tyden souteze o chronometr!

2003-10-13 Thread Raj fotaku

 Vazeni pratele
 dovolujeme si vam zaslat nasi aktualni nabidku potreb a sluzeb pro
digitalni fotografii ZA NEJLEPSI CENY. Prijdte si k nam vybrat ze siroke
nabidky pristroju na sklade nebo si vyberte z nasi nabidky na internetu;
vzdy dostanete kvalitni sluzby a spolehlive zbozi.

 POSLEDNI TYDEN Velke podzimni SOUTEZE O CHRONOMETR; HODINKY A DALSI
HODNOTNE CENY - vyhradne v Raji fotaku - sance na vyhru jsou velke! Vice
informaci na http://www.rajfotaku.cz/

 DigiBazar - digitalni fotoaparaty a prislusenstvi za vynikajici ceny; mnoho
noveho zbozi - najdete v oddile Digitalni pristroje->DigiBazar (nebo primo
www.rajfotaku.cz/ind_bazar.htm )

 Skoleni "ZPRACOVANI DIGITALNIHO VIDEA" je novinkou v nasi nabidce; pro
drzitele Klubovych karet Raje fotaku je SLEVA 10%. Podrobnosti najdete na
www.rajfotaku.cz .

 NOVINKY (podrobnosti na www.rajfotaku.cz)
 -Vyrazne SNIZENI CEN fotoaparatu Canon; Nikon; Sigma
 -Jiz je mozne objednavat Canon 300D; Fuji S5000; Minolta A1 a Z1; Pentax
*istD)
 -Nove v nabidce objektivy Sigma pro digitalni i analogove zrcadlovky Canon;
Olympus; Minolta; Nikon; Pentax
 -Zhotoveni digitalnich fotografii 10x15cm z digi fotoaparatu za 4.90Kc
 -SNIZENI CEN a rozsireni sortimentu digitalnich data/videoprojektoru
 -Nejlevnejsi pouzitelny digitalni fotak za 3.490Kc
 -Nove tuzkove akumulatory NexCell 2100mAh za skvelou cenu.
 -Zhotovujeme velkoformatove fotografie z digitalnich fotoaparatu (i
prusvitne pro svetelnou reklamu) do rozmeru 76cm x 400cm; klasickym
chemickym fotopostupem - kvalita je vyrazne vyssi nez bezne pouzivane plotry
nebo tiskarny!

 VYPRODEJ PREDVADECICH FOTOAPARATU (podrobnosti na www.rajfotaku.cz)
 -Minolta 7i
 -Olympus E10
 -Sony DSC-P72
 -Samsung Digimax V3

 
 AKCE-AKCE-AKCE
 -Velka podzimni soutez s NIKONEM o chronometr; naramkove hodinky a radu
dalsich cen. Podminky souteze na www.rajfotaku.cz !POSLEDNI TYDEN!
 -ZDARMA DARKY - elektronicka kucharka na CD - exkluzivni tricko - cepice -
hrnecek (s motivem digitalni fotografie jake jinde nedostanete!) ke kazdemu
koupenemu fotoaparatu
 -KLUBOVA KARTA Raje fotaku - spousta vyhod pro vas!

 Blizsi informace o sortimentu a ceny naleznete na adrese
 http://www.rajfotaku.cz/
 nebo si je vyzadejte u nasi firmy - kontaktni udaje jsou uvedeny nize.
Objednavat muzete e-mailem - telefonem - faxem nebo primo pomoci formulare
na webovych strankach.

 Pro objednavky nad 2.000Kc bez DPH je DOPRAVA V CR ZDARMA!

 Informace o novinkach a aktualnich akcich zasilame priblizne jednou za
mesic prostrednictvim tohoto mailoveho zpravodaje. Pokud nemate zajem
informace dostavat - zaslete nam prosim odpoved na tento e-mail. Do subjectu
uvedte NEPOSILAT a adresu na kterou jste jej obdrzeli. Pokud si nejste
adresou jisti-naleznete ji na konci tohoto mailu.

 Tesime se na dalsi spolupraci

 ---
 RAJ FOTAKU - Centrum digitalni fotografie

 Vas odborny fotoobchod!

 Sobeslavska 40; 130 01 Praha 3

 tel. 267 313 019; fax 271 731 762; 257 920 617

 e-mail [EMAIL PROTECTED]

 http://www.rajfotaku.cz/
 ---

Odesláno na adresu
[EMAIL PROTECTED];


--
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: setup hangs during postinstall

Christopher Faylor wrote:
>On Thu, Oct 09, 2003 at 06:17:08PM -0500, Brian Ford wrote:
>>#!/bin/bash
>>
>>FOO=`cygpath -S`
>>
>>but using #!/bin/sh doesn't.  likewise, strace hangs here:
>>#!/bin/bash
>>
>>FOO=`strace -o /tmp/cygpath.strace cygpath -S`
>>
>>but not using #!/bin/sh.
>>
>>Neither hang if setup is launched from bash instead of explorer.
>Hmm.  Maybe I missed this point before.  I never run setup from
>explorer.
>
>In any event, can you set the CYGWIN_DEBUG=cygpath and maybe do some
>search and destroy debugging to see precisely where it is hanging?
>
I finally got some time to look at this.  Preliminary results follow.
I'll try to poke more this afternoon if time permits.

Since setup must be launched from explorer to hang, I set
CYGWIN_DEBUG=cygpath in my system environment variables and rebooted.  To
make sure it worked, I launched a bash under rxvt and did a "cygpath -S".
Up popped the gdb cmd shell.  But, under setup, no dice.

cygpath hangs just like before.  The stack trace looks a little different.
Note that I have not had time to hand decode the holes in the trace yet,
but it looks to me like a startup problem before the CYGWIN_DEBUG
handling code.  A "fork exec copy" problem maybe?  I know that's vague,
but I think you know what I mean.

(gdb) info threads
  3 thread 213.0xb5  0x77f7645d in _system_dlls__ ()
  2 thread 213.0xd3  0x77f67fc7 in _system_dlls__ ()
* 1 thread 213.0xd7  0x77f6838b in _system_dlls__ ()
(gdb)i
#0  0x77f6838b in _system_dlls__ ()
#1  0x77f1d06a in _system_dlls__ ()
#2  0x61091027 in WFMO (nCount=3, lpHandles=0x1, fWaitAll=2147348480,
dwMilliseconds=4294967295)
at ../../../../cygwin/winsup/cygwin/sigproc.cc:1248
#3  0x6109344b in spawn_guts(char const*, char const* const*, char const* const*, int) 
(prog_arg=0xa044050 "/usr/bin/cygpath.exe", argv=0xa044b88,
envp=0xa044160, mode=3) at ../../../../cygwin/winsup/cygwin/spawn.cc:847
#4  0x6109477e in spawnve (mode=3, path=0xa044050 "/usr/bin/cygpath.exe",
argv=0xa044b88, envp=0xa044160)
at ../../../../cygwin/winsup/cygwin/spawn.cc:976
#5  0x6102835b in execve (path=0xa044050 "/usr/bin/cygpath.exe",
argv=0xa044b88, envp=0xa044160)
at ../../../../cygwin/winsup/cygwin/exec.cc:35
#6  0x004143c5 in ?? ()
[snip]
#24 0x00403a09 in [EMAIL PROTECTED] ()
#25 0x0040195f in get_short_paths(char*) (path=0x2 )
at ../../../../cygwin/winsup/utils/cygpath.cc:158
#26 0x610055c8 in dll_crt0_1() ()
at ../../../../cygwin/winsup/cygwin/dcrt0.cc:793
#27 0x61005a7d in _dll_crt0 () at ../../../../cygwin/winsup/cygwin/dcrt0.cc:921
#28 0x0047b901 in ?? ()
(gdb) thread 2
[Switching to thread 2 (thread 213.0xd3)]#0  0x77f67fc7 in _system_dlls__ ()
(gdb) bt
#0  0x77f67fc7 in _system_dlls__ ()
#1  0x610907c6 in wait_sig(void*) (self=0x610f0b40)
at ../../../../cygwin/winsup/cygwin/sigproc.cc:1089
#2  0x6100302e in cygthread::stub(void*) (arg=0x610f0b40)
at ../../../../cygwin/winsup/cygwin/cygthread.cc:69
#3  0x77f04eeb in _system_dlls__ ()

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

--
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: Setup Hangs in XFree86-bin-icons.sh

2003-10-13 Thread Cliff Hones

Harold Hunt wrote:
> This is a generic Cygwin problem, not related to XFree86.  The problem 
> is that cygpath hangs when called from a shell launched by setup.exe. 
> This problem has been reported many times before.  It started happening 
> about a month or two ago.  For a more detailed description, see my post 
> below:
> 
> http://www.cygwin.com/ml/cygwin-apps/2003-10/msg00049.html
> 
> 
> Nobody seems interested in fixing this, myself included, so it will most 
> likely remain broken.

This is not quite true.  The problem only occurs for a small
number of users, and until recently none of these have been able
or willing to debug it.  The core developers are getting frustrated
as they cannot reproduce the problem.  I believe some progress
is now being made (see Brian Ford's postings), so hopefully the
problem will soon be understood, and a fix is then likely to appear.

-- Cliff

--
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 with lilypond-profile.sh

2003-10-13 Thread Jan Nieuwenhuizen

> if I just missed something.
>
> You have to quote arguments inside [ ] or bad things(tm) happen.
AFAIK, that's only if you test something that can evaluate to empty,
eg:
$ test $FOO = "bar"
-bash: test: =: unary operator expected
$ test "$FOO" = "bar"
> In particular, without the below patch, rxvt is unable to run
> /bin/sh as a login shell and flashes a warning on the screen.
Strange, are you sure that the script gets sourced?  That's what the
test you changed is for, we had too many bugreports from people that
just run the script.  The downside to this test is that if you would
run (as opposed to source) the script from a login script, you may see
the flash and logout.
When when I source the script under ash 0.4.18 (Debian), the test
works:
$ set -x
$ . ./lilypond-profile
+ . ./lilypond-profile
+ [ -n  ]
+ basename ash
+ [ ash = lilypond-profile ]
etc.  While your patch will most probably not break anything, I'd like
to understand why it is needed.
Jan.
-- 
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien   | http://www.lilypond.org
Date: Mon, 13 Oct 2003 19:09:22 +0200
Message-ID: <[EMAIL PROTECTED]>


--
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: SSH connection close when _any_ user logs out of W2K

2003-10-13 Thread Corinna Vinschen

On Mon, Oct 13, 2003 at 05:58:45PM +0100, Dr.D.J.Picton wrote:
> 
> > Date: Mon, 13 Oct 2003 16:38:29 +0100 (BST)
> > From: "Dr.D.J.Picton" <[EMAIL PROTECTED]>
> > Subject: Re: SSH connection close when _any_ user logs out of W2K
> > To: [EMAIL PROTECTED]
> > Mime-Version: 1.0
> > Content-MD5: IFHKe0TcizXXvm44ktLQnA==
> > 
> > > Date: Mon, 13 Oct 2003 15:08:25 +0100 (BST)
> > > From: "Dr.D.J.Picton" <[EMAIL PROTECTED]>
> > > Subject: Re: SSH connection close when _any_ user logs out of W2K
> 
> > > >At 05:23 PM 9/30/2003, Matthew Hilty wrote:
> > > >>Hello,
> > > >>I've noticed on a recent installation of OpenSSH under cygwin
> > > >>(followed  http://tech.erdelynet.com/cygwin-sshd.html) that users
> > > >>connected to the server via SSH have their connections closed if any
> > > >>Windows user logs out of the desktop. The SSHD daemon still functions,
> > > >>it just closes active sessions.  After this, I can SSH back to the
> > > >>server and my session stays active until I intentionally log out, or
> > > >>another Windows users logs in, then out.
> 
> I've found a workaround!  You need to tell bash to ignore SIGHUP.  (This
> will also be inherited by processes started by the shell).
> 
> I added the following to /etc/profile, so that the shell will ignore
> SIGHUP in an interactive session started by sshd:
> 
> # Fix to sshd problem (any Windows logout kills interactive ssh sessions)
> if [ -n "$SSH_TTY" ]; then
>trap '' SIGHUP
> fi

Thanks for all that examining the situation.  I found the cause of that
problem in Cygwin and it should be solved in the next version.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

--
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: SSH connection close when _any_ user logs out of W2K

2003-10-13 Thread Dr.D.J.Picton


> Date: Mon, 13 Oct 2003 16:38:29 +0100 (BST)
> From: "Dr.D.J.Picton" <[EMAIL PROTECTED]>
> Subject: Re: SSH connection close when _any_ user logs out of W2K
> To: [EMAIL PROTECTED]
> Mime-Version: 1.0
> Content-MD5: IFHKe0TcizXXvm44ktLQnA==
> 
> > Date: Mon, 13 Oct 2003 15:08:25 +0100 (BST)
> > From: "Dr.D.J.Picton" <[EMAIL PROTECTED]>
> > Subject: Re: SSH connection close when _any_ user logs out of W2K

> > >At 05:23 PM 9/30/2003, Matthew Hilty wrote:
> > >>Hello,
> > >>I've noticed on a recent installation of OpenSSH under cygwin
> > >>(followed  http://tech.erdelynet.com/cygwin-sshd.html) that users
> > >>connected to the server via SSH have their connections closed if any
> > >>Windows user logs out of the desktop. The SSHD daemon still functions,
> > >>it just closes active sessions.  After this, I can SSH back to the
> > >>server and my session stays active until I intentionally log out, or
> > >>another Windows users logs in, then out.

I've found a workaround!  You need to tell bash to ignore SIGHUP.  (This
will also be inherited by processes started by the shell).

I added the following to /etc/profile, so that the shell will ignore
SIGHUP in an interactive session started by sshd:

# Fix to sshd problem (any Windows logout kills interactive ssh sessions)
if [ -n "$SSH_TTY" ]; then
   trap '' SIGHUP
fi




--
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/

Configure error

I recently downloaded Cygwin from cygwin.com, and everything
seems to be working fine.

Now when I try to compile any software using configure/make
routine, I keep getting the following error:

 configure: error: installation or configuration problem:
C++ compiler cannot create executables.

Digging into config.log, I see that its choking at the following
point:

configure:795: checking whether the C++ compiler (c++  ) works
configure:811: c++ -o conftestconftest.C  1>&5
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/libgcc.a(w32-shared-ptr.o)(.text+0x189):
undefined reference to `_pthread_atfork'
collect2: ld returned 1 exit status
configure: failed program was:

#line 806 "configure"
#include "confdefs.h"

int main(){return(0);}

Can anyone tell me what I'm doing wrong? Would appreciate
any help as I'm stuck at this point for a while.

Pankaj

---
Pankaj K Garg  [EMAIL PROTECTED]
1684 Nightingale Avenue408-373-4027
Sunnyvale, CA 94304
http://home.earthlink.net/~gargp


--
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: gcc -dM -E -xc /dev/null & g++ -dM -E -xc /dev/null

2003-10-13 Thread Rick Rankin


--- Christopher Faylor <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 13, 2003 at 07:22:28AM +0200, Alex Vinokur wrote:
> >gcc -dM -E -xc /dev/null
> >  and
> >g++ -dM -E -xc /dev/null
> >  produce the same output.
> >
> >Is this a feature or a bug?
> 
> It is not a bug.  Try it on linux.
> 
> >How can one know that g++ (not gcc) is invoked?
> 
> Isn't the __cplusplus define a feature of c++?  I'm too lazy to check if this
> is a g++ extension but I'd be surprised if it was.
> 

Yes, it's defined in section 16.8 (Predefined macro names) of the ANSI/ISO
standard.

--Rick

--
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: Possible bug in text/binary mode handling in cygwin1.dll version1.5

2003-10-13 Thread Vladimir Vysotsky

Jeff wrote:
Vlad wrote:
In other words, text mode is ignored if Windows-style path is
specified.
I noticed this same behavior and posted on it a bit earlier this month. 
Jeff, I've noticed your email after I've posted mine :) I believe it's
the same problem.
$ command -option `cygpath c:\whereever\whatever`
This is a great suggestion. The toolkit I'm dealing with uses an
environment variable TOOLKIT_ROOT, which used to be specified
Windows-style. Converting it to unix path seems to fix the compilation
problem.
I still wish cygwin1.dll would take care of this automatically.

Thanks,
Vlad
--
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: Setup Hangs in XFree86-bin-icons.sh

2003-10-13 Thread Harold L Hunt II

Laurence,

This is a generic Cygwin problem, not related to XFree86.  The problem 
is that cygpath hangs when called from a shell launched by setup.exe. 
This problem has been reported many times before.  It started happening 
about a month or two ago.  For a more detailed description, see my post 
below:

http://www.cygwin.com/ml/cygwin-apps/2003-10/msg00049.html

Nobody seems interested in fixing this, myself included, so it will most 
likely remain broken.

Harold

L. D. Marks wrote:

This is probably something that you already know, but
in case you don't there are some problems in XFree86-bin-icons.sh.
On my XP, it hangs. I went through various permutations,
e.g. deleting the scripts from /etc/postinstall,
/etc/preremove and /usr/X11R6/bin and reinstalling stuff without
finding anything that works (short of completely removing this
package). For reference, the date on the script is 9/29/2003.
---
Laurence Marks
Department of Materials Science and Engineering
MSE Rm 2036 Cook Hall
2225 N Campus Drive
Northwestern University
Evanston, IL 60201, USA
Tel: (847) 491-3996 Fax: (847) 491-7820
mailto:[EMAIL PROTECTED]
http://www.numis.northwestern.edu
---



--
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: merging mingw and cygwin