RE: Integrating Ralf's rebase into setup.exe

2003-01-02 Thread Ralf Habacker
 Still missing a lot of the errors that were fixed in my patch.  Here's 
 the remainder:
 
 1) 'hex' and 'endl' are also in the std:: namespace
 2) unbind_main.cc needs 'using namespace std;'
 3) (new) rebind_main will rebind the first commandline argument over and 
 over; it needs to use argv[i] not argv[1]
 4) fiximage.cc and rebaseimage.cc seem not have gotten any of the std:: 
 fixes.
 
 errmmm...why not inspect the patch below for correctness, and then apply 
  commit, rather than implementing all of the fixes by hand, which 
 invariably will skip/miss some?
 
Chuck, thanks for this patch. I have applied it. 

Regards 
Ralf 




RE: Integrating Ralf's rebase into setup.exe

2003-01-02 Thread Ralf Habacker
 Rob suggested libcygimagehlp.a for the library.

 Should we leave the names as is, but use -L and -I to find the right
 files instead?

If I remember right, this lib will be used for a cygwin based rebase and later
in the cygwin's setup application which is mingw based. So this lib must be
buildable for cygwin and mingw, isn't it ?

Additional I assume a standalone mingw based rebase would be also nice for the
mingw people.

Any comments ?

Ralf












RE: Integrating Ralf's rebase into setup.exe

2003-01-02 Thread Ralf Habacker
 Thats orthogonal (but IIRC is possible now/soon). The build within
 setup.exe will be a .a library, not a .dll. You could always use a
 compile flag to choose between cout error reporting and exceptions.

What about the following:

Step 1: library for standalone rebase

Every exported library function sets an error with SetLastError() and returns a
false condition, so a user could inspect this with GetLastError().
If the library must be debugged set SetImageHlpDebug(1) to enable debug message
printing.


Step 2:  library in setup.exe
add exception handling enabled by a -D option.


Step 1 is already in already supported.

Ralf





RE: Integrating Ralf's rebase into setup.exe

2003-01-02 Thread Robert Collins
On Thu, 2003-01-02 at 20:27, Ralf Habacker wrote:
  Rob suggested libcygimagehlp.a for the library.
 
  Should we leave the names as is, but use -L and -I to find the right
  files instead?
 
 If I remember right, this lib will be used for a cygwin based rebase and later
 in the cygwin's setup application which is mingw based. So this lib must be
 buildable for cygwin and mingw, isn't it ?

Yes. And the library should use the appropriate naming convention for
the target platform. I *don't* think it should be named libimagehlp.a,
because it's *not* a 100% replacement for libimagehlp.

Rob
-- 
---
GPG key available at: http://users.bigpond.net.au/robertc/keys.txt.
---



signature.asc
Description: This is a digitally signed message part


RE: Integrating Ralf's rebase into setup.exe

2003-01-02 Thread Robert Collins
On Thu, 2003-01-02 at 20:31, Ralf Habacker wrote:
  Thats orthogonal (but IIRC is possible now/soon). The build within
  setup.exe will be a .a library, not a .dll. You could always use a
  compile flag to choose between cout error reporting and exceptions.
 
 What about the following:
 
 Step 1: library for standalone rebase
 
 Every exported library function sets an error with SetLastError() and returns a
 false condition, so a user could inspect this with GetLastError().
 If the library must be debugged set SetImageHlpDebug(1) to enable debug message
 printing.

Sure. Reporting errors via SetLastError() is fine, its just saw the cout
 stuff in the patch, thus my comment.

Rob

-- 
---
GPG key available at: http://users.bigpond.net.au/robertc/keys.txt.
---



signature.asc
Description: This is a digitally signed message part


RE: Integrating Ralf's rebase into setup.exe

2003-01-02 Thread Ralf Habacker
  If I remember right, this lib will be used for a cygwin based
 rebase and later
  in the cygwin's setup application which is mingw based. So this lib must be
  buildable for cygwin and mingw, isn't it ?

 Yes. And the library should use the appropriate naming convention for
 the target platform.
 I *don't* think it should be named libimagehlp.a,
 because it's *not* a 100% replacement for libimagehlp.

You have already stated

 - libcygimagehlp  (for cygwin applications like rebase)

Do you mean

 - libmingwimagehlp

for setup.exe ?

What about the header ?  It could be the same in both variants. Symbolic linking
?

cygimagehlp.h
mingwimagehlp.h  - cygimagehlp.h

I think that's bad. The bfd library is named libbfd.xx on every platform, so
this library should be named in another way.

What about imagehelper.a and imagehelper.h and using autoconf stuff ?

Ralf




RE: Integrating Ralf's rebase into setup.exe

2003-01-02 Thread Robert Collins
On Thu, 2003-01-02 at 20:50, Ralf Habacker wrote:
 You have already stated
 
  - libcygimagehlp  (for cygwin applications like rebase)
 
 Do you mean
 
  - libmingwimagehlp
 
 for setup.exe ?

I really don't care, as long as it doesn't comflict with the real
imagehlp library.
 
 What about the header ?  It could be the same in both variants. Symbolic linking
 ?

Likewise.

Rob

-- 
---
GPG key available at: http://users.bigpond.net.au/robertc/keys.txt.
---



signature.asc
Description: This is a digitally signed message part


Re: Integrating Ralf's rebase into setup.exe

2003-01-02 Thread Jason Tishler
Ralf,

On Thu, Jan 02, 2003 at 10:27:12AM +0100, Ralf Habacker wrote:
 If I remember right, this lib will be used for a cygwin based rebase
 and later in the cygwin's setup application which is mingw based. So
 this lib must be buildable for cygwin and mingw, isn't it ?

My stand alone rebase is currently a Mingw app.  However, it was
initially a Cygwin app but I switched in over to Mingw when Chuck
pointed out that imagehlp.dll is dependent on msvcrt.dll.

Now that I will be using your rebase functionality instead, I have the
option to switch back to Cygwin.  For various reasons, I was intending
on keeping my stand alone rebase a Mingw app.  What do others think?

Thanks,
Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6



Re: Integrating Ralf's rebase into setup.exe

2003-01-02 Thread Jason Tishler
Ralf,

On Thu, Jan 02, 2003 at 04:23:08PM +0100, Ralf Habacker wrote:
  Now that I will be using your rebase functionality instead, I have
  the option to switch back to Cygwin.  For various reasons, I was
  intending on keeping my stand alone rebase a Mingw app.  What do
  others think?
 
 Hm, what about mingw and the stdlib++ library ? This library seems not
 to be part of the regular mingw package.

But, they are part of Cygwin gcc in Mingw mode (i.e., gcc -mno-cygwin).

Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6



Re: Integrating Ralf's rebase into setup.exe

2003-01-02 Thread Christopher Faylor
On Thu, Jan 02, 2003 at 04:23:08PM +0100, Ralf Habacker wrote:
 My stand alone rebase is currently a Mingw app.  However, it was
 initially a Cygwin app but I switched in over to Mingw when Chuck
 pointed out that imagehlp.dll is dependent on msvcrt.dll.

 Now that I will be using your rebase functionality instead, I have the
 option to switch back to Cygwin.  For various reasons, I was intending
 on keeping my stand alone rebase a Mingw app.  What do others think?

Hm, what about mingw and the stdlib++ library ? This library seems not to be
part of the regular mingw package.

libstdc++.a is part of the gcc-mingw package.

cgf



RE: Integrating Ralf's rebase into setup.exe

2003-01-02 Thread Ralf Habacker
 But, they are part of Cygwin gcc in Mingw mode (i.e., gcc -mno-cygwin).

You're right. My gcc installation was corrupted. Now I can compile it.

What about getopt, I can find the symbol in a library, but not the related
header. ?

I have installed mingw-runtime 2.2.1.

Ralf




Re: Integrating Ralf's rebase into setup.exe

2003-01-02 Thread Jason Tishler
Ralf,

On Thu, Jan 02, 2003 at 05:00:52PM +0100, Ralf Habacker wrote:
 What about getopt, ...

IIRC, it is not part of Mingw.

I just used a copy of getopt.[ch] from the Cygwin sources for my stand
alone rebase.

Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6



RE: Integrating Ralf's rebase into setup.exe

2003-01-02 Thread Ralf Habacker
 IIRC, it is not part of Mingw.

 I just used a copy of getopt.[ch] from the Cygwin sources for my stand
 alone rebase.

That curious: getopt is compiled into /usr/lib/mingw/libliberty.a; only the
header is missing.
I've copied the header from /usr/include/getopt.h to /usr/include/mingw and it
works.

Now it seme to works. I have checked in the recent version in the cvs.

Ralf




Re: Integrating Ralf's rebase into setup.exe

2003-01-02 Thread Charles Wilson
Ralf Habacker wrote:

Thats orthogonal (but IIRC is possible now/soon). The build within
setup.exe will be a .a library, not a .dll. You could always use a
compile flag to choose between cout error reporting and exceptions.



What about the following:

Step 1: library for standalone rebase



Step 1 is already in already supported.


Not really -- it doesn't compile anymore.  Among other things:

0) Update the changelog when you do stuff.  (You renamed the library 
itself, and that doesn't rate a mention in the ChangeLog?)

1) you need to 'cvs add imagehelper.h'
   (and 'rm imagehlp.h  cvs remove imagehlp.h')
   This is the biggie -- all of the .cc files now look for 
imagehelper.h -- but it isn't in CVS.

2) you probably should also
   rm imagehlpdebug.cc  cvs remove imagehlpdebug.cc
   since you're actually using the nearly identical 'debug.cc' file 
instead.

3) Makefile rule for REBASE_FILES should be changed back to
REBASE_FILES=rebase_main.o version.o $(LIB_TARGET_FILE)

4) You probably should use ar cru to create your static library, ar 
qf will flake unless you ranlib it each time.

5) is the 'bindimage.cc' file used at all?

6) I've got more, but they depend on the above things, which aren't 
really patches...

--Chuck



RE: Integrating Ralf's rebase into setup.exe

2003-01-02 Thread Ralf Habacker

 Not really -- it doesn't compile anymore.  Among other things:

You have gotten me just between finishing the things. I was interrupted a little
after written the last mail, so 10 minutes later is was mostly fixed.


 0) Update the changelog when you do stuff.  (You renamed the library
 itself, and that doesn't rate a mention in the ChangeLog?)

fixed
 1) you need to 'cvs add imagehelper.h'
 (and 'rm imagehlp.h  cvs remove imagehlp.h')
 This is the biggie -- all of the .cc files now look for
 imagehelper.h -- but it isn't in CVS.

fixed
 2) you probably should also
 rm imagehlpdebug.cc  cvs remove imagehlpdebug.cc
 since you're actually using the nearly identical 'debug.cc' file
 instead.

fixed
 3) Makefile rule for REBASE_FILES should be changed back to
 REBASE_FILES=rebase_main.o version.o $(LIB_TARGET_FILE)

fixed

 4) You probably should use ar cru to create your static library, ar
 qf will flake unless you ranlib it each time.


 5) is the 'bindimage.cc' file used at all?

it is used in rebind_main.cc.

Ralf






Re: Integrating Ralf's rebase into setup.exe

2003-01-02 Thread Charles Wilson
Ralf Habacker wrote:

You have gotten me just between finishing the things. I was interrupted a little
after written the last mail, so 10 minutes later is was mostly fixed.


Lucky me. g


5) is the 'bindimage.cc' file used at all?



it is used in rebind_main.cc.


You mean it *should* be used in rebind_main.cc. It's not listed in 
Makefile.in as one of the dependencies for REBIND_FILES, nor is it a 
member of LIBFILES.

Of course, rebind_main doesn't call BindImage or BindImageEx.  It does 
have a commented-out call to dll.rebind() -- but 
LinkedObjectFile::rebind() doesn't call BindImage() or BindImageEx 
either -- LinkedObjectFile::rebind() does all of the work itself.

Looks like the factorization isn't quite complete...work in progress, right?

Anyway, here's my remaining patches.  With two exceptions (Makefile and 
rebase_main.cc (main)), these are basically removing all printf calls 
and stdio.h, in favor of cout, cerr, and stream manipulators.

Anything that was printf() became std::cout, fprintf(stderr,) became 
cerr.  However, there are still some design issues that I didn't touch:

1) some that go to stdout probably should be stderr, and vice versa.
2) some are guarded by 'if (debug)' and probably should be 'if (some 
library call that returns the value of debug for this instance)' -- but 
I didn't really check the lexical scope.  These may be fine.
3) some aren't even guarded at all, and should be.
4) Then there's that whole exceptions vs. print-an-error-message from 
within the library deal.

The point is, ALL console output is now C++, cout/cerr style (before, it 
was half C++, half printf)

--Chuck


2002-01-02  Charles Wilson  [EMAIL PROTECTED]

	* Makefile.in: add bindimage.o to LIBFILES
	change ar flags for creating static library
	* bindimage.cc: include imagehelper.h
	* objectfile.cc: remove dependency on stdio.h, use
	iostream and iomanip instead.
	(ObjectFile::ObjectFile): use std::cout instead of
	printf, std::cerr instead of fprintf(stderr,...)
	(LinkedObjectFile::rebind): ditto.
	(LinkedObjectFile:LinkedObjectFile): ditto.
	(LinkedObjectFile::PrintDependencie): ditto.
	(LinkedObjectFile::unbind): ditto.
	(main): ditto.
	* objectfilelist.cc: remove dependency on stdio.h, use
	iostream instead.
	(main): use std::cout instead of
	printf, std::cerr instead of fprintf(stderr,...)
	* rebase_main.cc: remove dependency on stdio.h
	(main): don't call GetLastError() twice, use stored
	value in aStatus2.  Call strerror() for a more informative
	message.
	* rebind_main.cc: remove dependency on stdio.h
	(Usage): use std::cout instead of printf, std::cerr
	instead of fprintf(stderr,...)
	* sections.cc: remove dependency on stdio.h, use
	iostream and iomanip instead.
	(Section::print): use std::cout instead of printf, std::cerr
	instead of fprintf(stderr,...)
	(Exports::Exports): ditto.
	(Exports::dump): ditto.
	(Imports::Imports): ditto.
	(Imports::dump): ditto.
	(Relocations::check): ditto.
	(Relocations::fix): ditto.
	(Relocations::relocate): ditto.
	* unbind_main (Usage): ditto.
Index: Makefile.in
===
RCS file: /cvsroot/kde-cygwin/tools/rebase/Makefile.in,v
retrieving revision 1.1
diff -u -r1.1 Makefile.in
--- Makefile.in 2 Jan 2003 18:14:32 -   1.1
+++ Makefile.in 2 Jan 2003 18:35:56 -
@@ -9,7 +9,8 @@
 LIB_TARGET=imagehelper 
 LIB_TARGET_FILE=libimagehelper.a 
 LIB_FILES=objectfile.o objectfilelist.o sections.o debug.o \
-   rebaseimage.o checkimage.o fiximage.o 
getimageinfos.o 
+   rebaseimage.o checkimage.o fiximage.o 
+getimageinfos.o \
+   bindimage.o
 
 #
 # applications
@@ -33,7 +34,7 @@
 $(LIB_TARGET): $(LIB_TARGET_FILE)
 
 $(LIB_TARGET_FILE): $(LIB_FILES) 
-   ar -qf $@ $^
+   ar -cru $@ $^
 
 $(REBASE_TARGET): $(REBASE_FILES)
$(CXX) $(CXXFLAGS) -o $@ $^ $(LDFLAGS)
Index: bindimage.cc
===
RCS file: /cvsroot/kde-cygwin/tools/rebase/bindimage.cc,v
retrieving revision 1.5
diff -u -r1.5 bindimage.cc
--- bindimage.cc1 Jan 2003 11:55:49 -   1.5
+++ bindimage.cc2 Jan 2003 18:35:57 -
@@ -21,6 +21,7 @@
 #include iostream
 #include sstream
 
+#include imagehelper.h
 #include objectfile.h
 
 BOOL BindImageEx(
Index: objectfile.cc
===
RCS file: /cvsroot/kde-cygwin/tools/rebase/objectfile.cc,v
retrieving revision 1.6
diff -u -r1.6 objectfile.cc
--- objectfile.cc   2 Jan 2003 17:05:14 -   1.6
+++ objectfile.cc   2 Jan 2003 18:35:59 -
@@ -18,8 +18,9 @@
  * $Id: objectfile.cc,v 1.6 2003/01/02 17:05:14 habacker Exp $
  */
 
-#include stdio.h
 #include stdlib.h
+#include iostream
+#include iomanip
 #include time.h
 
 #include objectfile.h
@@ -78,7 +79,7 @@
   strcat(name,/);
   strcat(name,basename);
   if 

RE: Setup vertical scrollbar doesn't display

2003-01-02 Thread Gary R. Van Sickle
 --- Richard Garrison [EMAIL PROTECTED] wrote:
 The vertical scrollbar in the setup (initiated from
 the download now icon) doesn't display in my windows
 XP pro (service pack 1 - mobile PIII) box. Using the
 identical procedure on my windows 2k boxes works fine
 (the scrollbar displays).
 
 I didn't find anything about this on the web, the
 mailing list archives, or the FAQ (sorry in advance if
 i was blind).
 

It has been discussed before.  Maybe you searched the wrong list, or used the
lists' built-in search.  Don't bother with the latter; use Google, it'll find
hits in the archive.

 Tried changing the desktop theme to see if it was
 somehow related...it wasn't.
 

There are a number of issues with the chooser window's scroll bar.  Well, two
that I can recall: sporadic scrolly-wheel ignoring, and even more sporadic
not-showing-up-at-all.  Both are machine-related somehow; e.g. on my XP machine
at home, the scrolly wheel always works, on my XP machine at work it always
doesn't.  I haven't looked into it yet, but I suspect there's something going on
with the parent/owner relationships or some such Windows arcanery.  It's on the
list.  This too will pass... eventually.

--
Gary R. Van Sickle
Brewer.  Patriot.




Default OS Versions

2003-01-02 Thread Harold L Hunt II
Alan,

I doubt that this was the intended effect of using the default OS versions:
==
make[1]: Entering directory `/home/harold/x-devel/build/std'

Building on Cygwin
(DefaultOSMajorVersion.DefaultOSMinorVersion.DefaultOSTeenyVersion).

GCC version: 2.95
==


Any ideas?


Harold




Cross Compiling - Annoying warnings

2003-01-02 Thread Harold L Hunt II
I sat down tonight to do a great amount of programming.  Instead, I have
been tracking annoying build warnings and fighting with Windows XP to try to
tell it, no, I really do want to search every single file, not just the ones
that Microsoft products are known to store text in... anyway...

The build warnings are below; they repeat for every Imakefile that is
processed during the build.

Okay, forget about HasMakefileSafeInclude... I want to fix
UseInstalledOnCrossCompile first.

Now, UseInstalledOnCrossCompile is a YES/NO define, it is not a flag that is
either defined or not defined.  Thus, the following lines that declare it
are stupid:

/*
 * X-specific things
 */
#if CrossCompiling
# if defined UseInstalled  !defined UseInstalledOnCrossCompile
#  define UseInstalledOnCrossCompile YES
# endif
#endif


So, if you aren't cross compiling, or if you are but you didn't specify
UseInstalled, then the flag will simply not be defined.  It won't be defined
to NO, like it should be.

I made the following changes that seemed to clear up this set of error
messages:

/*
 * X-specific things
 */
#if CrossCompiling
# if defined UseInstalled  !defined UseInstalledOnCrossCompile
#  define UseInstalledOnCrossCompile YES
# else
#  define UseInstalledOnCrossCompile NO
# endif
#else
# define UseInstalledOnCrossCompile NO
#endif


Any comments?


Harold



make[3]: Entering directory `/home/harold/x-devel/build/std/include'
In file included from ../../config/cf/cygwin.cf:358,
 from ../../config/cf/Imake.tmpl:104,
 from Imakefile.c:14:
../../config/cf/cygwin.rules:408: warning: `HasMakefileSafeInclude' is not
defined
In file included from ../../config/cf/Imake.tmpl:1999,
 from Imakefile.c:14:
../../config/cf/X11.tmpl:1589: warning: `UseInstalledOnCrossCompile' is not
defined
In file included from ../../config/cf/Imake.tmpl:1999,
 from Imakefile.c:14:
../../config/cf/X11.tmpl:3383: warning: `UseInstalledOnCrossCompile' is not
defined
../../config/cf/X11.tmpl:3538: warning: `UseInstalledOnCrossCompile' is not
defined
../../config/cf/X11.tmpl:3559: warning: `UseInstalledOnCrossCompile' is not
defined
../../config/cf/X11.tmpl:3581: warning: `UseInstalledOnCrossCompile' is not
defined
../../config/cf/X11.tmpl:3633: warning: `UseInstalledOnCrossCompile' is not
defined
../../config/cf/X11.tmpl:3652: warning: `UseInstalledOnCrossCompile' is not
defined
../../config/cf/X11.tmpl:3724: warning: `UseInstalledOnCrossCompile' is not
defined
../../config/cf/X11.tmpl:3754: warning: `UseInstalledOnCrossCompile' is not
defined
../../config/cf/X11.tmpl:3770: warning: `UseInstalledOnCrossCompile' is not
defined
../../config/cf/X11.tmpl:3812: warning: `UseInstalledOnCrossCompile' is not
defined
make[3]: Leaving directory `/home/harold/x-devel/build/std/include'




src/winsup/w32api ChangeLog include/winnt.h

2003-01-02 Thread dannysmith
CVSROOT:/cvs/src
Module name:src
Changes by: [EMAIL PROTECTED]   2003-01-02 15:30:27

Modified files:
winsup/w32api  : ChangeLog 
winsup/w32api/include: winnt.h 

Log message:
* include/winnt.h (GetCurrentFiber): Remove blank input field
in asm code.
(GetFiberData): Likewise.

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.303r2=1.304
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/winnt.h.diff?cvsroot=srcr1=1.55r2=1.56




src/winsup/w32api ChangeLog lib/kernel32.c

2003-01-02 Thread dannysmith
CVSROOT:/cvs/src
Module name:src
Changes by: [EMAIL PROTECTED]   2003-01-02 16:04:22

Modified files:
winsup/w32api  : ChangeLog 
winsup/w32api/lib: kernel32.c 

Log message:
* lib/kernel32.c (GetCurrentFiber): Remove blank input field in
asm code.
(GetFiberData): Likewise.

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.304r2=1.305
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/lib/kernel32.c.diff?cvsroot=srcr1=1.3r2=1.4




winsup/cygwin ChangeLog dtable.cc dtable.h exc ...

2003-01-02 Thread cgf
CVSROOT:/cvs/uberbaum
Module name:winsup
Branch: cgf-dev-branch
Changes by: [EMAIL PROTECTED]  2003-01-02 22:17:24

Modified files:
cygwin : ChangeLog dtable.cc dtable.h exceptions.cc 
 pipe.cc 

Log message:
* dtable.h (dtable::in_vfork_cleanup): New function.  True if vfork cleanup
needed.
* dtable.cc (dtable::vfork_parent_restore): Remove assertion.
* pipe.cc (fhandler_pipe::close): Don't close read_state during fork_fixup
since it wasn't inherited.

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumonly_with_tag=cgf-dev-branchr1=1.1656.2.8r2=1.1656.2.9
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/dtable.cc.diff?cvsroot=uberbaumonly_with_tag=cgf-dev-branchr1=1.107.12.4r2=1.107.12.5
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/dtable.h.diff?cvsroot=uberbaumonly_with_tag=cgf-dev-branchr1=1.19.12.1r2=1.19.12.2
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/exceptions.cc.diff?cvsroot=uberbaumonly_with_tag=cgf-dev-branchr1=1.135.4.1r2=1.135.4.2
http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/pipe.cc.diff?cvsroot=uberbaumonly_with_tag=cgf-dev-branchr1=1.44.4.3r2=1.44.4.4




src/winsup/cygwin ChangeLog dtable.cc dtable.h ...

2003-01-02 Thread cgf
CVSROOT:/cvs/src
Module name:src
Changes by: [EMAIL PROTECTED]  2003-01-02 22:20:24

Modified files:
winsup/cygwin  : ChangeLog dtable.cc dtable.h exceptions.cc 
 pipe.cc 

Log message:
* dtable.h (dtable::in_vfork_cleanup): New function.  True if vfork cleanup
needed.
* dtable.cc (dtable::vfork_parent_restore): Remove assertion.
* pipe.cc (fhandler_pipe::close): Don't close read_state during fork_fixup
since it wasn't inherited.

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.1660r2=1.1661
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/dtable.cc.diff?cvsroot=srcr1=1.107r2=1.108
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/dtable.h.diff?cvsroot=srcr1=1.19r2=1.20
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/exceptions.cc.diff?cvsroot=srcr1=1.136r2=1.137
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/pipe.cc.diff?cvsroot=srcr1=1.44r2=1.45




perl error messages with cygwin 1.3.18-1

2003-01-02 Thread Greg Matheson
I am getting these Windows warning error messages with
perl-5.8.0. The programs continue after clicking the message.
This is better than the previous child process looping problem,
if not perfect ;-) 

PERL caused an invalid page fault in
module CYGWIN1.DLL at 017f:61084b28.
Registers:
EAX= CS=017f EIP=61084b28 EFLGS=00010206
EBX=00b97000 SS=0187 ESP=0073f338 EBP=0073f340
ECX=83b0c990 DS=0187 ESI=0073f368 FS=4f57
EDX=83b0c998 ES=0187 EDI=610c1a88 GS=
Bytes at CS:EIP:
8b 00 89 ec 5d c3 89 f6 55 89 e5 83 ec 08 a1 70 
Stack dump:
610df648 610c1a88 0073f380 61070c3c 610c1968  00b9510c
6108706b 0084 df0df046 0073f380 610895dc 610c1968 
0014 bff74277 

PERL caused an invalid page fault in
module CWD.DLL at 017f:00b92268.
Registers:
EAX= CS=017f EIP=00b92268 EFLGS=00010246
EBX=00b95000 SS=0187 ESP=0073f388 EBP=0073f390
ECX= DS=0187 ESI=00b9392c FS=1a67
EDX= ES=0187 EDI=610c1a88 GS=
Bytes at CS:EIP:
8b 11 85 d2 74 15 89 f6 39 5a 0c 74 60 8b 42 14 
Stack dump:
00b94000 0002 0073f3a0 00b91042 00b95000 0073f400 0073f3b0
61009aa3 00ba 00b9 0073f400 61009ee2 00ba0008 0073f3c8
001c 425c312d 

PERL caused an invalid page fault in
module GLOB.DLL at 017f:00b93c98.
Registers:
EAX= CS=017f EIP=00b93c98 EFLGS=00010246
EBX=00b97000 SS=0187 ESP=0073f448 EBP=0073f450
ECX= DS=0187 ESI=00b9536c FS=4a4f
EDX= ES=0187 EDI=610c1a88 GS=
Bytes at CS:EIP:
8b 11 85 d2 74 15 89 f6 39 5a 0c 74 60 8b 42 14 
Stack dump:
00b96000 0002 0073f460 00b91042 00b97000 0073f4c0 0073f470
61009aa3 00ba 00b9 0073f4c0 61009ee2 00ba0008 0073f488
001c 425c312d 

Other dlls like socket.dll also give similar warning messages.

-- 
Greg Matheson   Learn a second language and 
Chinmin College be born again, almost.
   
Taiwan Penpals Archive URL: http://penpals.chinmin.edu.tw/

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




ssmtp and cron

2003-01-02 Thread Dirk Ziegenbalg
Hello,

can somebody help me please
I've got cron and ssmtp to run. It works fine.
When cron is started and wants to mail me a message, then there was two error-entries 
in the eventlog und windows 2000. First tells me:

sSMTP mail : Win32 Process Id = 0x668 : Cygwin Process Id = 0x66C : unable to create a 
socket..

and the second:

sSMTP mail : Win32 Process Id = 0x668 : Cygwin Process Id = 0x66C : can't open the 
smtp port (25) on mail.gmx.de..

because of the first error.
When I call ssmtp from the commandline then it works fine.

I've give it up after two days of trying. Cron did his work. But I want his messages! 
Any ideas?


bye
Dirk

__
PREMIERE: Der Countdown laeuft! 3 Monate gratis + d-box 1 ab 1 Euro
nur noch wenige Tage zu haben! http://premiere.web.de/?mc=27lp=2


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




[ANNOUNCEMENT] Updated Cygwin Package: python-2.2.2-4

2003-01-02 Thread Jason Tishler
New News:
=== 
I have updated the version of Python to 2.2.2-4.  The tarballs should be
available on a Cygwin mirror near you shortly.

The main purpose of this release is to rebuild the _tkinter module
against the latest Cygwin tcltk package.

Additionally, the _socket module is *no* longer built as a static module
to workaround a Cygwin fork() issue due to DLL base address conflicts.
Note that this workaround does not works with the current Cygwin
release.  Instead, if you are experiencing fork() failures, then you
must rebase your Cygwin system.  See the README for more details.

Old News:
=== 
Python is an interpreted, interactive, object-oriented programming
language.  If interested, see the Python web site for more details:
   
http://www.python.org/ 

Please read the README file:

/usr/doc/Cygwin/python-2.2.2.README

since it covers requirements, installation, known issues, etc.

To update your installation, click on the Install Cygwin now link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

Note that we have recently stopped downloads from sources.redhat.com
(aka cygwin.com) due to bandwidth limitations.  This means that you will
need to find a mirror which has this update.

In the US,
ftp://mirrors.rcn.net/mirrors/sources.redhat.com/cygwin/
is a reliable high bandwidth connection.

In Germany,
ftp://ftp.uni-erlangen.de/pub/pc/gnuwin32/cygwin/mirrors/cygnus/
is usually pretty good.

In the UK,
http://programming.ccp14.ac.uk/ftp-mirror/programming/cygwin/pub/cygwin/
is usually up-to-date within 48 hours.

If one of the above doesn't have the latest version of this package
then you can either wait for the site to be updated or find another
mirror.

The setup.exe program will figure out what needs to be updated on your
system and will install newer packages automatically.

If you have questions or comments, please send them to the Cygwin
mailing list at: [EMAIL PROTECTED] .  I would appreciate if you would
use this mailing list rather than emailing me directly.  This includes
ideas and comments about the setup utility or Cygwin in general.

If you want to make a point or ask a question, the Cygwin mailing list
is the appropriate place.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the List-Unsubscribe:  tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

[EMAIL PROTECTED]

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: read() syscall broken on faster cpu?

2003-01-02 Thread Sascha Sommer
 On Wed, Jan 01, 2003 at 11:23:24PM +0100, Sascha Sommer wrote:
 Is it possible, that the read() syscall sometimes doesn't work correctly
on
 newer cpus?

 No.

 cgf

sorry my fault, cygwin was configured wrong on these machines

S. Sommer


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Heads up: *possible* bug in cygwin

2003-01-02 Thread Steven O'Brien
On Wed, 01 Jan 2003 18:39:08 -0500
Charles Wilson [EMAIL PROTECTED] wrote:

 Steven O'Brien wrote:
  My patch works around this problem by allocating a buffer of 1024
  bytes for cygwin. I think I got this value by reading the cygwin dll
  source to find a real upper bound, but it was a long time ago so
  this needs checking. 
 
 I saw this...it's probably a decent workaround, but hasn't yet been 
 accepted into current glib source AFAICT --- glib-2.2.0 still uses a
 64 byte buffer for reading pw entries.  But that's not where the
 segfault is happening in my case (as my earlier message showed).

Just to be clear, I did not see any failure in this function either. But
failures later (in gnome-vfs I think) were due to memory corruption
which went away when I increased this buffer to 1024 bytes.
Circumstantial evidence I know, but I raised this issue just in case it
helps with glib-2.0.x. 

Steven


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: 1.3.18-1: can't create title mutex

2003-01-02 Thread Roland Schwingel
Hi...


While running a big recursive make under Cygwin 1.3.18-1 on an SMP
system, I am getting occasional failures like these:

 C:\cygwin\bin\cygpath.exe: *** can't create title mutex, Win32 error 6
 C:\cygwin\bin\sh.exe: *** can't create title mutex, Win32 error 6

I am appending the output from cygcheck -s -v -r.  Let me know if I
should provide additional information.

- Pat


I can verify this here also... The same problems with it here (on a NON-SMP Machine W2K SP3)...
Especially with cypath... No problems yet with sh

I think I have to switch back to 1.3.17 or is there anything new found about it yet?

Roland




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: perl error messages with cygwin 1.3.18-1

2003-01-02 Thread Tommy Butler
Greg Matheson wrote:
 I am getting these Windows warning error messages with
 perl-5.8.0. The programs continue after clicking the message.
 This is better than the previous child process looping problem,
 if not perfect ;-)

 PERL caused an invalid page fault in
 module CYGWIN1.DLL at 017f:61084b28.
 Registers:
[snip]

No kidding!  Me too.  I tried installing 5.8 just the other day and experienced
this exact problem.  I thought, Hmmm, maybe if I build it myself I can get rid
of this.  Three unsuccessfully completed attempts and two hours later my
C:\WINDOWS\FAULTLOG.TXT had grown to over 2 megs in size.  It was full of those
happy illegal operation messages.  (Since the segfaults seemed to cause no
failures in the tests during make test, I had layed the phone on my carriage
return key after clicking the segv dialog box message about fifty times and went
out for a soda.)

Side note:  Hey Gerrit - the DBM dlls built flawlessly this time through :O)

I think this was only happening when something tried to fork().  Couldn't say
exactly.  Man, I'm ready for 5.8 but I've had to reinstall 5.6 back over it
after the last several attempts to use it since it was released.  Whether
installing directly via the cygwin installer or compiling it on my own, these
segfaults and several other odd behaviors keep occurring.  Total bummer for sure.

Further, perldoc.exe isn't rendering pages correctly since 5.8 either.  For
example, $ perldoc UNIVERSAL produces the following when run from cygwin bash
(quoted text snippet indented 3 spaces.)


   ESC[1mNAMEESC[0m
  UNIVERSAL - base class for ALL classes (blessed references)

   ESC[1mSYNOPSISESC[0m
  $io = $fd-isa(IO::Handle);
  $sub = $obj-can('print');

  $yes = UNIVERSAL::isa($ref, HASH);


   ESC[1mDESCRIPTIONESC[0m
  UNIVERSAL is the base class which all bless references will inherit
  from, see the perlobj manpage
...

Seems like escapes are getting printed out wrong...  Using man to read the
perldocs works just fine though.  Hope this gets fixed somehow (if it is a bug
indeed and not specific to my system.)  I'm also looking forward to using
podchecker in 5.8, which recognizes =header3 command paragraphs in PODs!

You're not alone Greg ;O)  But anyway, Go Cygwin!

-- 

  -Tommy Butler
   see if I'm online »http://ooopps.sourceforge.net/online

   Tommy Butler [EMAIL PROTECTED]
   phone: (817)-468-7716
   6711 Forest Park Dr
   Arlington, TX
76001-8403

   Download my résumé in PDF, MS Word, HTML, text
   http://www.atrixnet.com/

   the ooOPps Code Library
   http://ooopps.sourceforge.net/pub/



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Bailing out when calling LoadLibrary multiple times

2003-01-02 Thread Andre Vergison
Hello,

Calling a gcc made DLL by a MSVS 6.0 made EXE using LoadLibrary() and
 FreeLibrary() works perfectly.
However, closing the DLL and reopening it produces a segment violation.
This is not the case when the DLL is a MSVC made DLL.


How to reproduce :

1/ create a simple cygwin DLL :

foo.cpp:

#define DllExport__declspec( dllexport )

extern C {
DllExport int foo ();
}

int main(int argc, char** argv)
{
return 0;
}

DllExport int foo ()
{
return 0;
}


make it as follows:

gcc -c foo.cpp
gcc -shared -o foo.dll  foo.o



2/ Call this DLL using a MSVC 6.0 made program, something like this :

int main()
{
  ...
  HMODULE h = LoadLibrary(dll_path);
  FreeLibrary(h);
  h = LoadLibrary(dll_path);   -- bailing out here after stack
overflow
  ...
}


Thanks for any suggestion on how to avoid this.
Andre


--
cygcheck:

Cygwin Win95/NT Configuration Diagnostics
Current System Time: Tue Dec 31 16:37:02 2002

Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 3

Path:C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
c:\oracle\ora92\bin
c:\Program Files\Oracle\jre\1.3.1\bin
c:\Program Files\Oracle\jre\1.1.8\bin
c:\WINNT\system32
c:\WINNT
c:\WINNT\System32\Wbem
c:\bin32
c:\Program Files\Common Files\Compuware\NMShared
c:\Program Files\Compuware\DevPartner Studio\Analysis
c:\Program Files\Compuware\DevPartner Studio\Distributed Analyzer
C
C:\cygwin\Program Files\Norton SystemWorks\Norton Ghost\
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
C:\cygwin\cygwin\c\PlsOEM\PLF
c:\PlsOEM\PLF

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

HOME = `C:\cygwin\home\avg'
MAKE_MODE = `unix'
PWD = `/home/avg/plf'
USER = `avg'

ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\avg\Application Data'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `ANDRE'
COMSPEC = `C:\WINNT\system32\cmd.exe'
FMTTRACE = `capi'
HOMEDRIVE = `C:'
HOMEPATH = `\'
LOGONSERVER = `\\ANDRE'
MANPATH = `:/usr/ssl/man'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/home/avg'
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 15 Model 1 Stepping 2, GenuineIntel'
PROCESSOR_LEVEL = `15'
PROCESSOR_REVISION = `0102'
PROGRAMFILES = `C:\Program Files'
PROMPT = `$P$G'
PS1 = `\[\033]0;\w\007
\033[32m\]\u@\h \[\033[33m\w\033[0m\]
$ '
SHLVL = `2'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINNT'
TEMP = `c:\DOCUME~1\avg\LOCALS~1\Temp'
TERM = `cygwin'
TMP = `c:\DOCUME~1\avg\LOCALS~1\Temp'
USERDOMAIN = `ANDRE'
USERNAME = `avg'
USERPROFILE = `C:\Documents and Settings\avg'
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
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
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) = `C:\cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `C:\cygwin/bin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `C:\cygwin/lib'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts
v2\/usr/X11R6/lib/X11/fonts
  (default) = `C:\cygwin\usr\X11R6\lib\X11\fonts'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

a:  fd   N/AN/A
c:  hd  NTFS   38161Mb  55% CP CS UN PA FC Local Disk
d:  hd  NTFS   76308Mb  88% CP CS UN PA FC DATA
e:  cd   N/AN/A
f:  hd  NTFS   117796Mb  70% CP CS UN PA FC IOMEGA 1
g:  hd  NTFS   117796Mb  47% CP CS UN PA FC IOMEGA 3
n:  net NTFS   70001Mb  87% CP CS UN PA FC Local Disk
x:  net NTFS   70001Mb  87% CP CS UN PA FC Local Disk
y:  net NTFS   70001Mb  52% CP CS UN PA FC Local Disk

C:\cygwin  / system  binmode
C:\cygwin/bin  /usr/bin  system  binmode
C:\cygwin/lib  /usr/lib  system  binmode
C:\cygwin\usr\X11R6\lib\X11\fonts  /usr/X11R6/lib/X11/fonts  system  binmode
.  /cygdrive user
binmode,cygdrive

Found: C:\cygwin\bin\bash.exe
Found: C:\cygwin\bin\cat.exe
Found: C:\cygwin\bin\cpp.exe
Found: C:\cygwin\bin\find.exe
Found: C:\cygwin\bin\gcc.exe
Found: C:\cygwin\bin\gdb.exe
Found: C:\cygwin\bin\ld.exe
Found: C:\cygwin\bin\ls.exe
Found: C:\cygwin\bin\make.exe
Found: 

Re: Prioprietary DLL link problem - Can't export...

2003-01-02 Thread Robert Bercik
Hi guys,

 I'm still trying to figure out how to fix this.
I've been scouring the internet looking for anyone
who's had a similar problem and someone mentioned
creating a definition file. Do I need to pass a .def
file to the linker. I really could use some help,
thanks guys...

-Rob 

--- Robert Bercik [EMAIL PROTECTED] wrote:
 Hi,
 
  I am trying to link to a proprietary dll and
 I'm
 so damn close I 
 can almost taste the sweet sweet linkage. But i got
 a
 little error. 
 It's says it cannot find some symbols and therefore
 the export fails? 
 Maybe you guys can help clarify,
 heres' what gcc says:
 
 make files.dll
 make[1]: Entering directory
 `/cygdrive/c/source-code/run306'
 gcc -DCYGWIN -DINLINE_4WS -w -L/usr/local/lib -L.
 -I. 
 -I/cygdrive/c/Oracle/Ora81
 /oci/include -v -shared -o files.dll
 -Wl,--export-all-symbols files.o 
 handle.o a
 bort.o attrst.o calendar.o cdate.o datemm.o crm.o
 endwin.o 
 fire_triggers.o get_h
 elp.o get_tble.o getf.o getgroup.o getun.o hwin.o
 init_pan.o logdf.o 
 pager.o put
 f.o read_pan.o refsh.o remark.o replay.o routines.o
 simple.o sfattr.o 
 sfclos.o s
 fcset.o sfdisp.o sfgeta.o sfgeti.o sfgetk.o sfgetp.o
 sfopen.o sfposr.o 
 sfsetp.o
 sysinf.o sfsrea.o sfssho.o sfswri.o strings.o swin.o
 ice_api.o 
 exec_sql.o change
 _file_group.o -lm -lcurses -lcygipc 
 /cygdrive/c/Oracle/Ora81/oci/lib/msvc/ociw32
 .lib /cygdrive/c/cobol32/lib/MFRTS32.LIB
 Reading specs from
 /usr/lib/gcc-lib/i686-pc-cygwin/3.2/specs
 Configured with: /netrel/src/gcc-3.2-3/configure 
 --enable-languages=c,c++,f77,ja
 va --enable-libgcj --enable-threads=posix
 --with-system-zlib 
 --enable-nls --with
 out-included-gettext --enable-interpreter
 --disable-sjlj-exceptions 
 --disable-ve
 rsion-specific-runtime-libs --enable-shared
 --build=i686-pc-linux 
 --host=i686-pc
 -cygwin --target=i686-pc-cygwin --enable-haifa
 --prefix=/usr 
 --exec-prefix=/usr
 --sysconfdir=/etc --libdir=/usr/lib
 --includedir=/nonexistent/include 
 --libexecd
 ir=/usr/sbin
 Thread model: posix
 gcc version 3.2 20020927 (prerelease)
  /usr/lib/gcc-lib/i686-pc-cygwin/3.2/collect2.exe
 --shared -Bdynamic -e 
 __cygwin
 _dll_entry@12 --dll-search-prefix=cyg -o files.dll 
 /usr/lib/gcc-lib/i686-pc-cygw
 in/3.2/crtbegin.o -L/usr/local/lib -L. 
 -L/usr/lib/gcc-lib/i686-pc-cygwin/3.2 -L/
 usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../..
 --export-all-symbols 
 files.o handle.
 o abort.o attrst.o calendar.o cdate.o datemm.o crm.o
 endwin.o 
 fire_triggers.o ge
 t_help.o get_tble.o getf.o getgroup.o getun.o hwin.o
 init_pan.o logdf.o 
 pager.o
 putf.o read_pan.o refsh.o remark.o replay.o
 routines.o
 simple.o 
 sfattr.o sfclos.
 o sfcset.o sfdisp.o sfgeta.o sfgeti.o sfgetk.o
 sfgetp.o sfopen.o 
 sfposr.o sfsetp
 .o sysinf.o sfsrea.o sfssho.o sfswri.o strings.o
 swin.o ice_api.o 
 exec_sql.o cha
 nge_file_group.o -lm -lcurses -lcygipc 
 /cygdrive/c/Oracle/Ora81/oci/lib/msvc/oci
 w32.lib /cygdrive/c/cobol32/lib/MFRTS32.LIB -lgcc
 -lcygwin -luser32 
 -lkernel32 -
 ladvapi32 -lshell32 -lgcc
 /usr/lib/gcc-lib/i686-pc-cygwin/3.2/crtend.o
 Cannot export NULL_IMPORT_DESCRIPTOR: symbol not
 found
 Cannot export mfrts32_IMPORT_DESCRIPTOR: symbol not
 found
 Cannot export #8962;OCIW32_NULL_THUNK_DATA: symbol
 not
 found
 Cannot export #8962;mfrts32_NULL_THUNK_DATA: symbol
 not found
 Info: resolving _stdscr by linking to __imp__stdscr
 (auto-import)
 Info: resolving _curscr by linking to __imp__curscr
 (auto-import)
 collect2: ld returned 1 exit status
 make[1]: *** [files.dll] Error 1
 make[1]: Leaving directory
 `/cygdrive/c/source-code/run306'
 make: *** [default] Error 2
 
 
 __
 Do you Yahoo!?
 Yahoo! Mail Plus - Powerful. Affordable. Sign up
 now.
 http://mailplus.yahoo.com
 
 --
 Unsubscribe info: 
 http://cygwin.com/ml/#unsubscribe-simple
 Bug reporting: http://cygwin.com/bugs.html
 Documentation: http://cygwin.com/docs.html
 FAQ:   http://cygwin.com/faq/
 


__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Bug somewhere between cygwin, gcc and cvs

2003-01-02 Thread Arkadiy Belousov
Hello All!

The newest cygwin DLL version (from 12/25) helped. I've recompiled with 
-O2, and now it works fine. Thank you very, very much.

You may be missing the fact that saying a problem with opening a directory
is not equivalent to saying Cygwin isn't supposed to work this way.

Pierre Humblet submitted a patch to fix a problem opening directories on
Windows 9x/Me last week.

So, as always, trying a new cygwin snapshot is a good idea.

cgf







--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Prioprietary DLL link problem - Can't export...

2003-01-02 Thread Robert Bercik
Alright, I'm replying to my own email because I
figured out the problem and maybe this could be
beneficial to others having the same problem at a
later time. I created a .def file which contained all
of the symbols I was exporting using the methods found
here:

http://www.cygwin.com/cygwin-ug-net/dll.html

note that this definition file did NOT include the
symbols the compiler was complaining about like
NULL_IMPORT_DESCRIPTOR. Then you give the definition
file as an arguement to gcc along with all of your
object files, mine looked like this:

gcc -L/usr/local/lib -L. -I.
-I/cygdrive/c/Oracle/Ora81
/oci/include -Wall -shared -o  files.dll files.o
handle.o files.def -lcurses

specifying the files.def file made it stop complaining
about those other symbols. 

Good Luck,
-Rob



--- Robert Bercik [EMAIL PROTECTED] wrote:
 Hi guys,
 
  I'm still trying to figure out how to fix this.
 I've been scouring the internet looking for anyone
 who's had a similar problem and someone mentioned
 creating a definition file. Do I need to pass a .def
 file to the linker. I really could use some help,
 thanks guys...
 
 -Rob 
 
 --- Robert Bercik [EMAIL PROTECTED] wrote:
  Hi,
  
   I am trying to link to a proprietary dll and
  I'm
  so damn close I 
  can almost taste the sweet sweet linkage. But i
 got
  a
  little error. 
  It's says it cannot find some symbols and
 therefore
  the export fails? 
  Maybe you guys can help clarify,
  heres' what gcc says:
  
  make files.dll
  make[1]: Entering directory
  `/cygdrive/c/source-code/run306'
  gcc -DCYGWIN -DINLINE_4WS -w -L/usr/local/lib -L.
  -I. 
  -I/cygdrive/c/Oracle/Ora81
  /oci/include -v -shared -o files.dll
  -Wl,--export-all-symbols files.o 
  handle.o a
  bort.o attrst.o calendar.o cdate.o datemm.o crm.o
  endwin.o 
  fire_triggers.o get_h
  elp.o get_tble.o getf.o getgroup.o getun.o hwin.o
  init_pan.o logdf.o 
  pager.o put
  f.o read_pan.o refsh.o remark.o replay.o
 routines.o
  simple.o sfattr.o 
  sfclos.o s
  fcset.o sfdisp.o sfgeta.o sfgeti.o sfgetk.o
 sfgetp.o
  sfopen.o sfposr.o 
  sfsetp.o
  sysinf.o sfsrea.o sfssho.o sfswri.o strings.o
 swin.o
  ice_api.o 
  exec_sql.o change
  _file_group.o -lm -lcurses -lcygipc 
  /cygdrive/c/Oracle/Ora81/oci/lib/msvc/ociw32
  .lib /cygdrive/c/cobol32/lib/MFRTS32.LIB
  Reading specs from
  /usr/lib/gcc-lib/i686-pc-cygwin/3.2/specs
  Configured with: /netrel/src/gcc-3.2-3/configure 
  --enable-languages=c,c++,f77,ja
  va --enable-libgcj --enable-threads=posix
  --with-system-zlib 
  --enable-nls --with
  out-included-gettext --enable-interpreter
  --disable-sjlj-exceptions 
  --disable-ve
  rsion-specific-runtime-libs --enable-shared
  --build=i686-pc-linux 
  --host=i686-pc
  -cygwin --target=i686-pc-cygwin --enable-haifa
  --prefix=/usr 
  --exec-prefix=/usr
  --sysconfdir=/etc --libdir=/usr/lib
  --includedir=/nonexistent/include 
  --libexecd
  ir=/usr/sbin
  Thread model: posix
  gcc version 3.2 20020927 (prerelease)
   /usr/lib/gcc-lib/i686-pc-cygwin/3.2/collect2.exe
  --shared -Bdynamic -e 
  __cygwin
  _dll_entry@12 --dll-search-prefix=cyg -o files.dll
 
  /usr/lib/gcc-lib/i686-pc-cygw
  in/3.2/crtbegin.o -L/usr/local/lib -L. 
  -L/usr/lib/gcc-lib/i686-pc-cygwin/3.2 -L/
  usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../..
  --export-all-symbols 
  files.o handle.
  o abort.o attrst.o calendar.o cdate.o datemm.o
 crm.o
  endwin.o 
  fire_triggers.o ge
  t_help.o get_tble.o getf.o getgroup.o getun.o
 hwin.o
  init_pan.o logdf.o 
  pager.o
  putf.o read_pan.o refsh.o remark.o replay.o
  routines.o
  simple.o 
  sfattr.o sfclos.
  o sfcset.o sfdisp.o sfgeta.o sfgeti.o sfgetk.o
  sfgetp.o sfopen.o 
  sfposr.o sfsetp
  .o sysinf.o sfsrea.o sfssho.o sfswri.o strings.o
  swin.o ice_api.o 
  exec_sql.o cha
  nge_file_group.o -lm -lcurses -lcygipc 
  /cygdrive/c/Oracle/Ora81/oci/lib/msvc/oci
  w32.lib /cygdrive/c/cobol32/lib/MFRTS32.LIB -lgcc
  -lcygwin -luser32 
  -lkernel32 -
  ladvapi32 -lshell32 -lgcc
  /usr/lib/gcc-lib/i686-pc-cygwin/3.2/crtend.o
  Cannot export NULL_IMPORT_DESCRIPTOR: symbol not
  found
  Cannot export mfrts32_IMPORT_DESCRIPTOR: symbol
 not
  found
  Cannot export #8962;OCIW32_NULL_THUNK_DATA: symbol
  not
  found
  Cannot export #8962;mfrts32_NULL_THUNK_DATA:
 symbol
  not found
  Info: resolving _stdscr by linking to
 __imp__stdscr
  (auto-import)
  Info: resolving _curscr by linking to
 __imp__curscr
  (auto-import)
  collect2: ld returned 1 exit status
  make[1]: *** [files.dll] Error 1
  make[1]: Leaving directory
  `/cygdrive/c/source-code/run306'
  make: *** [default] Error 2
  
  
  __
  Do you Yahoo!?
  Yahoo! Mail Plus - Powerful. Affordable. Sign up
  now.
  http://mailplus.yahoo.com
  
  --
  Unsubscribe info: 
  http://cygwin.com/ml/#unsubscribe-simple
  Bug reporting: http://cygwin.com/bugs.html
  Documentation: http://cygwin.com/docs.html
  FAQ:   http://cygwin.com/faq/
  
 
 
 

Cygwin gcc initializer element is not constant problem

2003-01-02 Thread Jason Tishler
The attached code snippet, j2.c, demonstrates a Cygwin specific
compilation problem that affects many Python shared extension modules:

$ gcc -c j2.c
j2.c:17: initializer element is not constant
j2.c:17: (near initialization for `f.get')

It appears that Cygwin gcc considers function pointers marked
__declspec(dllimport) unacceptable to use as initializer constants.

My standard workaround is to submit a patch that is the equivalent of
compiling this snippet with -DWORKAROUND:

$ gcc -DWORKAROUND -c j2.c

Unfortunately, this style of patch is no longer acceptable:

http://mail.python.org/pipermail/python-dev/2002-December/031534.html

Can anyone suggest a better (hopefully less intrusive) workaround?

Thanks,
Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

typedef void (*function)();

struct foo
{
function get;
};

__declspec(dllimport) void f1();

struct foo f =
{
#ifndef WORKAROUND
f1
#else
0
#endif
};

void
init()
{
#ifdef WORKAROUND
f.get = f1;
#endif
}


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/


RE: ssmtp and cron

2003-01-02 Thread Harig, Mark A.

As requested at http://cygwin.com/bugs.html:

o Most of the information about your Cygwin environment
  is listed by running 'cygcheck -s -v -r  cygcheck.txt'.
  Please include cygcheck.txt *AS AN ATTACHMENT* to your
  report.  It is important that you include it as an
  attachment so that searches of the mailing-list archives
  give fewer false matches.

o Also, it would be useful if you included the steps you
  took to set up ssmtp, possibly including the contents
  of configuration file(s).

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




lockf() or flock() support?

2003-01-02 Thread Robert Bercik
I'm porting an application that uses lockf() to cygwin
and it doesn't appear that either are supported on
cygwin. If so i can't seem to find which library they
are contained in. Anybody have any luck with either of
these?

thanks,
-Rob

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




lockf() or flock() support?

2003-01-02 Thread Robert Bercik
I'm porting an application that uses lockf() to cygwin
and it doesn't appear that either are supported on
cygwin. If so i can't seem to find which library they
are contained in. Anybody have any luck with either of
these?

thanks,
-Rob

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




ZoneAlarm and OpenSSH

2003-01-02 Thread Lynn Wilson
ZoneAlarm Pro contains code that is designed to stop trojans by popping up a 
dialog window and asking the computer user whether a given process should be 
allowed to have access to the internet.  The user can elect to deny the access 
attempt or to accept it AND the user can also elect to remember the answer for 
this particular process and automatically allow it access in any future attempts.

A while back I began noticing that occasionally (not always!) I would get a 
popup when running ssh asking whether I should allow access to Object 80002839. 
 The actual number varies each time.  Since it is not the same number, I can 
not tell ZoneAlarm to always allow it to have access.

Does anyone have a workaround for this problem?  I have scripts that I want to 
run from cron on a remote machine that does not have a regular human operator. 
I also need parts of ZoneAlarm that prevent outside access except from known IP 
addresses.  Windows that pop-up and halt operations until a human interacts with 
it are not a good thing.

Where changes made to OpenSSH recently that caused this to occur or was I just 
not paying attention?  Suggestions welcomed.

Lynn


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Issue with stringstream class

2003-01-02 Thread Silqun Leung
Hello,
I am having some difficulty with the stringstream class.  Here is a
simple program I run:
 
#include sstream
#include iostream
#include string
 
int main(int argc, char* argv[])
{
 std::string temp;
 
 std::string stuff = asdf asdf asdf asdf asdf;  std::stringstream a;
 
 a  stuff.c_str();
 std::cout  a.str()  std::endl;
 
 a  temp;
 std::cout  a.str();
 
 return 0;
}
 
The output when built with g++ is:
asdf asdf asdf asdf asdf
asdf asdf asdf asdf asdf
 
This is not what I expect when using the  operator.  I looked at the
stringstream class and do not see it overloading the  operator and believe
that it should be inheriting from the same place as the ifstream class. When
I use the  operator on a std::ifstream object, it is destructive, however
this does not appear to be the case for the stringstream object (which I
believe it should be).  Using the same program with Visual C++ will yield
correct results (ie. an output of asdf asdf asdf asdf asdf asdf asdf asdf
asdf
 
Is this a bug in the implementation of the stringstream class?
 
Thanks,
Silqun

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Cygwin home dir=/cygwin/c (not /home/userid)

2003-01-02 Thread Igor Pechtchanski
On Tue, 31 Dec 2002, a12 wrote:

 Hello,
 I have just installed the latest Cygwin release on one PC.

The two issues you mention are unrelated.  See below.

 It is up and running OK, except that all local users login into
 /cygdrive/c instead of /home/userid.

Do you have the /etc/passwd and /etc/group files?  If you do, are any of
the local users in /etc/passwd?  What is their home directory set to?
Try rebuilding your /etc/passwd and /etc/group:

$ for i in (/etc/passwd /etc/group); do mv $i ${i}-backup; done
$ mkpasswd -l  /etc/passwd
$ mkgroup -l  /etc/group

and see if you still get that problem.

 The length of PATH in DOS is 97 characters, and in cygwin 148
 characters:

 Path=C:\WINNT\System32;C:\WINNT;C:\WINNT\System32\Wbem;C:\Program 
Files\Centura2.0\;C:\cygwin\bin

 
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
  1 2 3 4 5 6 7 8 
9 0 1 2 3 4

 
/usr/local/bin:/usr/bin:/bin:Path=C:/WINNT/System32:/cygdrive/c/WINNT:/cygdrive/c/WINNT/System32/Wbem:/cygdrive/c/Program
 Files/Centura2.0/:/usr/bin

 What have I missed ?

The fact that Cygwin translates the Windows path to a POSIX path using the
mount information.  Also the fact that you have Path= as part of the
VALUE of the PATH variable.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
  -- /usr/games/fortune


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Heads up: *possible* bug in cygwin

2003-01-02 Thread Jason Tishler
Chuck,

On Wed, Jan 01, 2003 at 11:36:49PM -0500, Charles Wilson wrote:
 Turns out, the problem IS in newlib.

I concur.  In fact, this problem is the root cause for the Cygwin Python
SEGV that I was trying to debug in the following:

http://cygwin.com/ml/cygwin-developers/2002-12/msg00027.html

For those interested, Python's test_format regression test would SEGV
after trying to display a 109 digit number.  Unfortunately, this
occurred deep in Python's garbage collection during exit which threw me
off the track.  Sigh...

Thanks for your astute analysis.  With the attached patch, I was able
to get test_format to pass.  I will monitor the newlib list to see what
the outcome is.

Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

Index: newlib/libc/stdlib/ldtoa.c
===
RCS file: /cvs/src/src/newlib/libc/stdlib/ldtoa.c,v
retrieving revision 1.6
diff -u -p -r1.6 ldtoa.c
--- newlib/libc/stdlib/ldtoa.c  12 Nov 2002 21:47:53 -  1.6
+++ newlib/libc/stdlib/ldtoa.c  2 Jan 2003 19:12:30 -
@@ -36,7 +36,7 @@ void _IO_ldtostr(long double *, char *, 
  /* Maximum number of decimal digits in ASCII conversion
   * = NBITS*log10(2)
   */
- #define NDEC (NBITS*8/27)
+ #define NDEC 256 // (NBITS*8/27)
 
  /* The exponent of 1.0 */
  #define EXONE (0x3fff)
@@ -2750,8 +2750,8 @@ if( ndigits  NDEC )
 ndigits = NDEC;
 
 /* reentrancy addition to use mprec storage pool */
-_REENT_MP_RESULT(ptr) = Balloc (ptr, 3);
-_REENT_MP_RESULT_K(ptr) = 3;
+_REENT_MP_RESULT(ptr) = Balloc (ptr, 5);
+_REENT_MP_RESULT_K(ptr) = 5;
 outstr = (char *)_REENT_MP_RESULT(ptr);
 
 etoasc( e, outstr, ndigits, mode, ldp );


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/


Cygwin copy / paste problem with accentued characters

2003-01-02 Thread Frédéric L. W. Meunier
It seems that I'm not able to copy / paste accentued characters
from Command Prompt to Cygwin and between Cygwin.

I write the following on the bash prompt:

ÁáãçaÉ

I copy it to the Command Prompt:

ÁáãçaÉ

Now I copy it to the same bash prompt:

ça

The same if I copy it to another bash prompt.

It happens with all other applications, not only bash. I tested
with Lynx, Midnight Commander's internal editor, and others.

What could be wrong ? Accents work everywhere. Using XP
Professional SP1 with all updates. Brazilian ABNT2 keyboard.

BTW, to make some accentued characters (like É and all with ~)
work under Cygwin I had to set

Regional and Language Options - Regional Options - Advanced

to Portuguese (Brazil). All worked on Command Prompt with
English (United States).

Am I missing some Code page conversion tables under the same
window ? Which ?

TIA.

-- 
0@pervalidus.{net, {dyndns.}org}

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: 1.3.18-1: can't create title mutex

2003-01-02 Thread Igor Pechtchanski
On Thu, 2 Jan 2003, Roland Schwingel wrote:

 Hi...

  While running a big recursive make under Cygwin 1.3.18-1 on an SMP
  system, I am getting occasional failures like these:
 
   C:\cygwin\bin\cygpath.exe: *** can't create title mutex, Win32 error 6
   C:\cygwin\bin\sh.exe: *** can't create title mutex, Win32 error 6
 
  I am appending the output from cygcheck -s -v -r.  Let me know if I
  should provide additional information.
 
  - Pat

 I can verify this here also... The same problems with it here (on a
 NON-SMP Machine W2K SP3)... Especially with cypath... No problems yet
 with sh

 I think I have to switch back to 1.3.17 or is there anything new found
 about it yet?

 Roland

This wouldn't have anything to do with Cygwin trying to set the title of
the window to the name of the executing program?  Just a WAG, but adding
notitle to your CYGWIN environment variable might be a way out.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
  -- /usr/games/fortune


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




RE: 1.3.18-1: can't create title mutex

2003-01-02 Thread Stephan Bachofen
I get the same since I updated to 1.3.18. 1.3.17 was fine.
I get it when I try to compile with ant:

$ ant
C:\apps\cygwin\bin\cygpath.exe: *** can't create title mutex, Win32
error 6
Error: JAVA_HOME is not defined correctly.
  We cannot execute java

About no title: I tried:
export CYGWIN=notitle

but didn't help me.



-Original Message-
From: Igor Pechtchanski [mailto:[EMAIL PROTECTED]] 
Sent: 02 January 2003 19:36
To: Roland Schwingel
Cc: [EMAIL PROTECTED]
Subject: Re: 1.3.18-1: can't create title mutex

On Thu, 2 Jan 2003, Roland Schwingel wrote:

 Hi...

  While running a big recursive make under Cygwin 1.3.18-1 on an SMP
  system, I am getting occasional failures like these:
 
   C:\cygwin\bin\cygpath.exe: *** can't create title mutex, Win32
error 6
   C:\cygwin\bin\sh.exe: *** can't create title mutex, Win32 error 6
 
  I am appending the output from cygcheck -s -v -r.  Let me know if
I
  should provide additional information.
 
  - Pat

 I can verify this here also... The same problems with it here (on a
 NON-SMP Machine W2K SP3)... Especially with cypath... No problems yet
 with sh

 I think I have to switch back to 1.3.17 or is there anything new found
 about it yet?

 Roland

This wouldn't have anything to do with Cygwin trying to set the title of
the window to the name of the executing program?  Just a WAG, but adding
notitle to your CYGWIN environment variable might be a way out.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big*
RAMdisk!
  -- /usr/games/fortune


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Cygwin gcc initializer element is not constant problem

2003-01-02 Thread Igor Pechtchanski
On Thu, 2 Jan 2003, Jason Tishler wrote:

 The attached code snippet, j2.c, demonstrates a Cygwin specific
 compilation problem that affects many Python shared extension modules:

 $ gcc -c j2.c
 j2.c:17: initializer element is not constant
 j2.c:17: (near initialization for `f.get')

 It appears that Cygwin gcc considers function pointers marked
 __declspec(dllimport) unacceptable to use as initializer constants.

 My standard workaround is to submit a patch that is the equivalent of
 compiling this snippet with -DWORKAROUND:

 $ gcc -DWORKAROUND -c j2.c

 Unfortunately, this style of patch is no longer acceptable:

 http://mail.python.org/pipermail/python-dev/2002-December/031534.html

 Can anyone suggest a better (hopefully less intrusive) workaround?

 Thanks,
 Jason

Jason,

I believe the complaint was not about the intrusiveness (i.e. patch size)
of the workaround, but about the readability of the resulting code.

How about doing exactly what the message suggests (see attached)?
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
  -- /usr/games/fortune

#ifndef WORKAROUND
#  define INITIAL(v) (v)
#  define ASSIGN(f,v)
#else
#  define INITIAL(v) (0)
#  define ASSIGN(f,v) do{ f = v; }while(0)
#endif

typedef void (*function)();

struct foo
{
function get;
};

__declspec(dllimport) void f1();

struct foo f =
{
INITIAL(f1)
};

void
init()
{
ASSIGN(f.get, f1);
}


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/


rxvt problems

2003-01-02 Thread Douglas WF Acheson
Hello,

  I am using rxvt 2.7.0 release 4 with my version of cygwin under W2K
with SP3.  The problem I am having is that when the line exceeds a
certain number of characters, say 94 for example, then new characters
start to appear at the beginning of the line (like line-wrap but with
not carriage return).  This is very annoying.

  I believe this has something to do with my termcap file but not sure.
Any help resolving this would be great.  Thanks ...



=
Douglas WF Acheson

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: Heads up: *possible* bug in cygwin

2003-01-02 Thread Charles Wilson
Jason Tishler wrote:

I concur.  In fact, this problem is the root cause for the Cygwin Python
SEGV that I was trying to debug in the following:

http://cygwin.com/ml/cygwin-developers/2002-12/msg00027.html

For those interested, Python's test_format regression test would SEGV
after trying to display a 109 digit number.  Unfortunately, this
occurred deep in Python's garbage collection during exit which threw me
off the track.  Sigh...

Thanks for your astute analysis.  With the attached patch, I was able
to get test_format to pass.  I will monitor the newlib list to see what
the outcome is.


But that's just *wrong*.  You simply move the error condition to larger 
strings.  NDEC=42 actually makes sense -- that's (relatively close to) 
the most base-10 digits that a floating point number can represent (not 
counting those infinitely repeating base-10 numbers thanks to floating 
point roundoff -- e.g. where the closest representation to 0.1 in 
base-2 float is (after reconverting to base-10) 0.9.).

Of course, my solution for glib (inside pkgconfig-0.14) is even worse: 
don't do that.  I simply changed the format string to %42.42f instead 
of %1.1f.  g  It's not a glib problem, after all, so for now I 
just work around it -- and hope that an acceptable solution for the 
newlib issue is found. [I don't mind coding that solution, but I dunno 
what the Right Thing to do is...I'm waiting for guidance from the 
newlib list]

--Chuck


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: Heads up: *possible* bug in cygwin

2003-01-02 Thread Jason Tishler
Chuck,

On Thu, Jan 02, 2003 at 03:18:45PM -0500, Charles Wilson wrote:
 Jason Tishler wrote:
 Thanks for your astute analysis.  With the attached patch, I was able
   ^  ^
   *  *

 But that's just *wrong*.

Of course.  Did you notice the quotes?  My patch (I'm using the term
*very* loosely) was just to verify that we both stumbled across the same
problem.  Which we did.

 Of course, my solution for glib (inside pkgconfig-0.14) is even worse: 
 don't do that.  I simply changed the format string to %42.42f instead 
 of %1.1f.

This is not an option for me.  Python would never accept such a patch.

 and hope that an acceptable solution for the newlib issue is found. [I
 don't mind coding that solution, but I dunno what the Right Thing to
 do is...I'm waiting for guidance from the newlib list]

Me too!

Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Can I Cross-Compile and x86 Linux Kernel under Cygwin?

2003-01-02 Thread Thomas Chadwick
I'm looking for a convenient place to cross-compile a Linux Kernel 
targetting an x86 platform.  Is this something I can do under Cygwin, or am 
I asking for trouble?  While I've compiled the Linux kernel before, I've 
never cross-compiled it on a different platform.


_
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE* 
http://join.msn.com/?page=features/virus


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: Cygwin gcc initializer element is not constant problem

2003-01-02 Thread Jason Tishler
Igor,

On Thu, Jan 02, 2003 at 03:03:21PM -0500, Igor Pechtchanski wrote:
 How about doing exactly what the message suggests (see attached)?

I think that I found the best solution -- auto-import the functions by
just removing the __declspec(dllimport) indicators.  If interested,
see attached.

Thanks,
Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

---BeginMessage---
On Tue, Dec 31, 2002 at 05:14:17PM -0500, Tim Peters wrote:
 Please don't make this kind of change -- it makes the code so much
 harder to follow.  If this is needed for Cygwin, then, e.g., do
 
 [snip]

I believe that I have found a cleaner solution to this problem.
Cygwin's ld can auto-import functions:

http://www.cygwin.com/ml/cygwin-apps/2001-08/msg00024.html

Specifically, the following snippet is the most pertinent:

We always have allowed 'auto-import' of *functions* that are
exported by the DLL (as long as the DLL contains the appropriate
symbols).

Note I don't believe that always pertained when I first started down
this path in the Python 2.0 time frame.

Anyway, with the attached patch to pyport.h, I was able to build Cygwin
Python without any errors.  Note this includes the new datetime module
from CVS -- not the patched one in sandbox.

I feel this is the best approach because modules should build under
Cygwin without the standard Cygwin style patch that I have been
submitting for years.  Do others concur?  If so, then I will begin to
clean up the mess that I have created.

Now if SF could search for patches by the submitter, my job would be a
little easier...

Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

Index: pyport.h
===
RCS file: /cvsroot/python/python/dist/src/Include/pyport.h,v
retrieving revision 2.57
diff -u -p -r2.57 pyport.h
--- pyport.h28 Dec 2002 21:56:07 -  2.57
+++ pyport.h2 Jan 2003 20:51:50 -
@@ -429,7 +429,11 @@ and both these use __declspec()
 #  else /* Py_BUILD_CORE */
/* Building an extension module, or an embedded situation */
/* public Python functions and data are imported */
-#  define PyAPI_FUNC(RTYPE) __declspec(dllimport) RTYPE
+#  if defined(__CYGWIN__)
+#  define PyAPI_FUNC(RTYPE) RTYPE
+#  else /* __CYGWIN__ */
+#  define PyAPI_FUNC(RTYPE) __declspec(dllimport) RTYPE
+#  endif /* __CYGWIN__ */
 #  define PyAPI_DATA(RTYPE) extern __declspec(dllimport) RTYPE
/* module init functions outside the core must be exported */
 #  if defined(__cplusplus)

---End Message---
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/


Re: Cygwin home dir=/cygwin/c (not /home/userid)

2003-01-02 Thread a12
Hello Igor,

Thank you for your reply.

Following your reply I have rebuilt /etc/group and /etc/passwd

/etc/group:
SYSTEM:S-1-5-18:18:
none:S-1-5-21-18958337-794100916-1409357915-513:513:
admins:S-1-5-32-544:544:
backup:S-1-5-32-551:551:
guests:S-1-5-32-546:546:
power:S-1-5-32-547:547:
replicator:S-1-5-32-552:552:
users:S-1-5-32-545:545:
domain:S-1-5-21-220523388-688789844-725345543-513:10513:

/etc/passwd:
SYSTEM:*:18:544:,S-1-5-18::
admins:*:544:544:,S-1-5-32-544::
guest:*:501:513:U-GJ2QF0J\Guest,S-1-5-21-18958337-794100916-1409357915-501:/home/Guest:/bin/bash
isoft:*:1002:513:RR 
isoft,U-GJ2QF0J\isoft,S-1-5-21-18958337-794100916-1409357915-1002:/home/isoft:/bin/bash
patrol:*:1015:513:patrol,U-GJ2QF0J\patrol,S-1-5-21-18958337-794100916-1409357915-1015:/home/patrol:/bin/bash
sshd:*:1016:513:sshd 
privsep,U-GJ2QF0J\sshd,S-1-5-21-18958337-794100916-1409357915-1016:/var/empty:/bin/bash
sysaccount:*:1000:513:U-GJ2QF0J\sysaccount,S-1-5-21-18958337-794100916-1409357915-1000:/home/sysaccount:/bin/bash
magr40:*:12085:10513:magr40,U-TCAD\magr40,S-1-5-21-220523388-688789844-725345543-102085:/home/magr40:/bin/bash

Whether I login locally as user 'sysaccount' or domain user
'magr40', the problem persists:
HOME=/cygdrive/c
HOMEDRIVE=C:
HOMEPATH=\

/etc/profile is enclosed.

Any more hints ?


Igor Pechtchanski wrote:

 On Tue, 31 Dec 2002, a12 wrote:

  Hello,
  I have just installed the latest Cygwin release on one PC.

 The two issues you mention are unrelated.  See below.

  It is up and running OK, except that all local users login into
  /cygdrive/c instead of /home/userid.

 Do you have the /etc/passwd and /etc/group files?  If you do, are any of
 the local users in /etc/passwd?  What is their home directory set to?
 Try rebuilding your /etc/passwd and /etc/group:

 $ for i in (/etc/passwd /etc/group); do mv $i ${i}-backup; done
 $ mkpasswd -l  /etc/passwd
 $ mkgroup -l  /etc/group

 and see if you still get that problem.

  The length of PATH in DOS is 97 characters, and in cygwin 148
  characters:
 
  Path=C:\WINNT\System32;C:\WINNT;C:\WINNT\System32\Wbem;C:\Program 
Files\Centura2.0\;C:\cygwin\bin
 
  
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
   1 2 3 4 5 6 7 8   
  9 0 1 2 3 4
 
  
/usr/local/bin:/usr/bin:/bin:Path=C:/WINNT/System32:/cygdrive/c/WINNT:/cygdrive/c/WINNT/System32/Wbem:/cygdrive/c/Program
 Files/Centura2.0/:/usr/bin
 
  What have I missed ?

 The fact that Cygwin translates the Windows path to a POSIX path using the
 mount information.  Also the fact that you have Path= as part of the
 VALUE of the PATH variable.
 Igor
 --
 http://cs.nyu.edu/~pechtcha/
   |\  _,,,---,,_[EMAIL PROTECTED]
 ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
  |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski
 '---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

 Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
   -- /usr/games/fortune

 --
 Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
 Bug reporting: http://cygwin.com/bugs.html
 Documentation: http://cygwin.com/docs.html
 FAQ:   http://cygwin.com/faq/

PATH=/usr/local/bin:/usr/bin:/bin:$PATH
unset DOSDRIVE
unset DOSDIR
unset TMPDIR
unset TMP

#mwe: set the umask to allow for creation of files with 644 and directories
# with 755.
umask 022

USER=`id -un`

#mwe: set a HOSTNAME variable to the host name in lower case letters
export HOSTNAME=`hostname|tr '[A-Z]' '[a-z]'`

# Set up USER's home directory
if [ -z $HOME ]; then
  HOME=/home/$USER
fi

if [ ! -d $HOME ]; then
  mkdir -p $HOME
fi

#mwe: create a .inputrc file that allows for case insensitive file/directory
#mwe: completion
if [ ! -e $HOME/.inputrc ]; then
  echo 'set completion-ignore-case on'  $HOME/.inputrc
  chmod 644 $HOME/.inputrc
fi

export HOME USER

for i in /etc/profile.d/*.sh ; do
  if [ -f $i ]; then
. $i
  fi
done

export MAKE_MODE=unix

#mwe: There may be cases when you log on using ASH (/bin/sh) rather than BASH.
# in this case, you'll have to set up the prompt and lack of aliases
# differently.
if [ ! -z $BASH ]; then
  #mwe: set the prompt to include [user@host], current working directory,
  # {history number} and either $ or #.
  export PS1='[$USER@$HOSTNAME]\w:{\!}:\$ '
  test -f ./.bashrc  . ./.bashrc

  #mwe: if aliases files exist, read them.
  test -f /etc/sh_aliases  . /etc/sh_aliases
  test -f ./.aliases  . ./.aliases
else
  #mwe: Since Ash doesn't support aliases, we'll use a shell function to replace
  # the regular cd command with one that changes directory AND changes the
  # prompt to reflect the current directory.
  cd() {
chdir $1
export 

Re: Cygwin home dir=/cygwin/c (not /home/userid)

2003-01-02 Thread Pierre A. Humblet
On Thu, Jan 02, 2003 at 11:15:09PM +0100, a12 wrote:

 Whether I login locally as user 'sysaccount' or domain user
 'magr40', the problem persists:
 HOME=/cygdrive/c
 HOMEDRIVE=C:
 HOMEPATH=\

Isn't HOME already defined in the Windows environment, before 
starting Cygwin?
Start a DOS shell and type echo %HOME%

Pierre

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: convert utility

2003-01-02 Thread Joshua Daniel Franklin
 What caused me a problem in searching, is that convert is a rather 
 common word. From what I was told by an acquainance on a non 
 computer list, imagine that, since my initial post is this is part of 
 imagemagick.  Currently downloading it so my question should be 
 resolved assuming I can get it to compile ;)

Just for posterity, I assume that you soon found this page:

http://www.imagemagick.org/www/QuickStart.html

which has links to download, among others, 

ImageMagick-i686-pc-cygwin.tar.gz


__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




incredibile.............

2003-01-02 Thread jennifer........
NEWSLETTER PER ADULTI V.M.


http://penetrazionianali.isfun.net

IL MEGLIO DEL WEB

http://penetrazionianali.isfun.net

SE NON VUOI PIU RICEVERE

PIU POSTA SCRIVI

[EMAIL PROTECTED]



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: convert utility

2003-01-02 Thread Elfyn McBratney
It seems my mail didn't get through to the list. I've never heard of a
mail taking 2 days to get through the MTA...

 Have you by any chance looked at the main cygwin (http://cygwin.com/)
 homepage? As you'll see on the right-hand side

 ImageMagick 5.4.6 (ftp://ftp.imagemagick.org/pub/ImageMagick/binaries/)
 Jun 18 2002, Bob Friesenhahn

 ImageMagick has been ported to cygwin.

 There's also a good image-toolkit (including a conversion utility) 
 called netpbm, which from what I've been told, compiles OOTB.

Happy new year everyone... Better late than never ;^)

Elfyn
[EMAIL PROTECTED]


--- Joshua Daniel Franklin [EMAIL PROTECTED] wrote:
 What caused me a problem in searching, is that convert is a rather 
 common word. From what I was told by an acquainance on a non 
 computer list, imagine that, since my initial post is this is part of 
 imagemagick.  Currently downloading it so my question should be 
 resolved assuming I can get it to compile ;)

Just for posterity, I assume that you soon found this page:

http://www.imagemagick.org/www/QuickStart.html

which has links to download, among others, 

ImageMagick-i686-pc-cygwin.tar.gz


__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

_
www.smokeJet.com - Free UK Internet Services

_
Select your own custom email address for FREE! Get [EMAIL PROTECTED] w/No Ads, 6MB, 
POP  more! http://www.everyone.net/selectmail?campaign=tag

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




__RUNTIME_PSEUDO_RELOC_LIST[_END]__ (1.3.18-1)

2003-01-02 Thread Timothy C Prince
I've been looking unsuccessfully for an explanation of these undefined symbols in 
libcygwin.a(pseudo-reloc.o).  I take it this is a new feature of 1.3.18-1, but until 
I see the usage explained, I guess I'll keep reverting to 1.3.17-1.
Tim Prince

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




__RUNTIME_PSEUDO_RELOC_LIST[_END]__ (1.3.18-1)

2003-01-02 Thread Elfyn McBratney
The pseudo reloc is a new addition to cygwin-1.3.18-1. Taken from the
release announce
(http://www.cygwin.com/ml/cygwin-announce/2002-12/msg00031.html)

  - Implement pseudo reloc code which now allows transparent linking
  of dlls similar to UNIX.  (Egor Duda)

What problems are you experiencing? The symbols
__RUNTIME_PSEUDO_RELOC_LIST__ and __RUNTIME_PSEUDO_RELOC_LIST_END__ are exported by 
binutils, so have you updated that recently?

Elfyn
[EMAIL PROTECTED]

_
www.smokeJet.com - Free UK Internet Services

_
Select your own custom email address for FREE! Get [EMAIL PROTECTED] w/No Ads, 6MB, 
POP  more! http://www.everyone.net/selectmail?campaign=tag

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




RE: 1.3.18-1: can't create title mutex

2003-01-02 Thread Cristian Southall
I received the same error after running cygcheck a few times and then
trying to 'man cygcheck' ...

$ man cygcheck
C:\cygwin\bin\sh.exe: *** can't create title mutex, Win32 error 6
C:\cygwin\bin\sh.exe: *** can't create title mutex, Win32 error 6
fgets: No such file or directory
Error reading man page /usr/man/man1/cygcheck.1.gz
No manual entry for cygcheck

Trying to run cygcheck after this returns ...

$ cygcheck -svr  ~/cygcheck.txt
cygcheck: dump_sysinfo: GetVolumeInformation() failed: 87

Opening another window temporarily solves the problem.

Cygcheck output is attached.

crist



__
Cristian Southall BA(Hons)
Analyst/Programmer, JDV
Phone (B/H): +61 8 9266 0263






 Stephan Bachofen [EMAIL PROTECTED] 01/03/03 03:55AM

I get the same since I updated to 1.3.18. 1.3.17 was fine.
I get it when I try to compile with ant:

$ ant
C:\apps\cygwin\bin\cygpath.exe: *** can't create title mutex, Win32
error 6
Error: JAVA_HOME is not defined correctly.
  We cannot execute java

About no title: I tried:
export CYGWIN=notitle

but didn't help me.



-Original Message-
From: Igor Pechtchanski [mailto:[EMAIL PROTECTED]] 
Sent: 02 January 2003 19:36
To: Roland Schwingel
Cc: [EMAIL PROTECTED] 
Subject: Re: 1.3.18-1: can't create title mutex

On Thu, 2 Jan 2003, Roland Schwingel wrote:

 Hi...

  While running a big recursive make under Cygwin 1.3.18-1 on an SMP
  system, I am getting occasional failures like these:
 
   C:\cygwin\bin\cygpath.exe: *** can't create title mutex, Win32
error 6
   C:\cygwin\bin\sh.exe: *** can't create title mutex, Win32 error 6
 
  I am appending the output from cygcheck -s -v -r.  Let me know
if
I
  should provide additional information.
 
  - Pat

 I can verify this here also... The same problems with it here (on a
 NON-SMP Machine W2K SP3)... Especially with cypath... No problems
yet
 with sh

 I think I have to switch back to 1.3.17 or is there anything new
found
 about it yet?

 Roland

This wouldn't have anything to do with Cygwin trying to set the title
of
the window to the name of the executing program?  Just a WAG, but
adding
notitle to your CYGWIN environment variable might be a way out.
Igor
-- 
http://cs.nyu.edu/~pechtcha/ 
  |\  _,,,---,,_[EMAIL PROTECTED] 
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED] 
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big*
RAMdisk!
  -- /usr/games/fortune


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple 
Bug reporting: http://cygwin.com/bugs.html 
Documentation: http://cygwin.com/docs.html 
FAQ:   http://cygwin.com/faq/ 


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple 
Bug reporting: http://cygwin.com/bugs.html 
Documentation: http://cygwin.com/docs.html 
FAQ:   http://cygwin.com/faq/ 


JDV - e-Commerce and Outsourcing Solutions for Financial Services
http://www.jdv.com/

JDV is a division of Hartleys Limited ABN 67 009 136 029 (JDV).
Any securities recommendation contained in this document is unsolicited
general information only. Do not act on a recommendation without first
consulting your investment advisor to determine whether the
recommendation is appropriate for your investment objectives, financial
situation and particular needs.
JDV  believes that any information or advice (including any securities
recommendation) contained in this document is accurate when issued.
However, JDV does not warrant its accuracy or reliability. JDV, its
officers, agents and employees exclude all liability whatsoever,
in negligence or otherwise, for any loss or damage relating to this
document to the full extent permitted by law.
JDV may collect personal information from you in order to provide any
services you have requested.  A copy of JDV's privacy policy is
available at http://www.jdv.com/



Cygwin Win95/NT Configuration Diagnostics
Current System Time: Fri Jan 03 09:06:31 2003

Windows NT Ver 4.0 Build 1381 Service Pack 6

Path:   C:\cygwin\usr\sbin
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
c:\WINNT\system32
c:\WINNT
c:\WINNT\system32\nls\ENGLISH
c:\WINNT\system32\nls
c:\Sybase\DLL
c:\Sybase\BIN
c:\DMINT40\WIN32\Bin
c:\WINNT\system32
c:\WINNT
c:\WINNT\system32\nls\ENGLISH
c:\WINNT\system32\nls
c:\Sybase\DLL
c:\Sybase\BIN
c:\DMINT40\WIN32\Bin
c:\java\j2sdk1.4.1_01\bin
C:\cygwin\bin
c:\Program Files\SSH Communications Security\SSH Secure Shell
c:\java\tools
Z
.
Y
.
C:\cygwin\usr\X11R6\bin

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

CYGWIN = `tty glob ntsec'
HOME = `C:\cygwin\home\csouthall'

can

2003-01-02 Thread Robert Bercik
 
 

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Setup vertical scrollbar doesn't display

2003-01-02 Thread Richard Garrison
The vertical scrollbar in the setup (initiated from
the download now icon) doesn't display in my windows
XP pro (service pack 1 - mobile PIII) box. Using the
identical procedure on my windows 2k boxes works fine
(the scrollbar displays).

I didn't find anything about this on the web, the
mailing list archives, or the FAQ (sorry in advance if
i was blind).

Tried changing the desktop theme to see if it was
somehow related...it wasn't.

All i want to do is install some packages (XFree)
beyond the scope of the window. I can't seem to find a
way to fool the installer. (i tried dowloading
everything i needed onto the win2k box (where the
scrollbar displayed)...and then copying it all to the
xp box, hoping that the install preferences would
followthey didn't)

Any help would behelpful?



__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




RE: Heads up: *possible* bug in cygwin

2003-01-02 Thread Gary R. Van Sickle
 Chuck,

 On Wed, Jan 01, 2003 at 11:36:49PM -0500, Charles Wilson wrote:
  Turns out, the problem IS in newlib.

 I concur.  In fact, this problem is the root cause for the Cygwin Python
 SEGV that I was trying to debug in the following:

 http://cygwin.com/ml/cygwin-developers/2002-12/msg00027.html

 For those interested, Python's test_format regression test would SEGV
 after trying to display a 109 digit number.  Unfortunately, this
 occurred deep in Python's garbage collection during exit which threw me
 off the track.  Sigh...

 Thanks for your astute analysis.  With the attached patch, I was able
 to get test_format to pass.  I will monitor the newlib list to see what
 the outcome is.

 Jason


Free software is so very, very sweet.  Thanks to everybody involved in killing
this latent (to me anyway) defect.

--
Gary R. Van Sickle
Brewer.  Patriot.




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




gcc and libtiff, maybe a newbie question

2003-01-02 Thread Henrik Bengtsson
Hi, first I haven't done C programming in years and am a bit rusty with
gcc and ld. I am having problems with ld reporting undefined reference
to _TIFFOpen etc, which should be in libtiff. However, I am not even
sure if the problem is about libtiff or if miss something else.

Here is my minimize code I am trying to compile and link (write.c):

#include stdio.h
#include tiff.h
#include tiffio.h

int main(int argc, char *argv[]) {
  TIFF *image;

  if((image = TIFFOpen(output.tif, w)) == NULL){
printf(Could not open output.tif for writing\n);
exit(42);
  }
  TIFFClose(image);
}

I get the following error:
% gcc -static -lm -ltiff -o write.o -ltiff write.c
/tmp/ccfugoHj.o(.text+0x76):write.c: undefined reference to `_TIFFOpen'
/tmp/ccfugoHj.o(.text+0xa2):write.c: undefined reference to `_TIFFClose'
collect2: ld returned 1 exit status

According to the following troubleshooting it looks like it finds
libtiff.a (or something):
% gcc -static -lm -ltiffX -o write.o -ltiff write.c
/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../../i686-pc-cygwin/bin/ld:
cannot fi
nd -ltiffX
collect2: ld returned 1 exit status

According to Cygwin Setup the tiff version is 3.5.7-1. gcc is v3.2
(20020927). 

% ls -l /usr/lib/libtiff.*
-rwx--+   1 hb   None   316100 Feb 10  2002
/usr/lib/libtiff.a
-rwx--+   1 hb   None   152620 Feb 10  2002
/usr/lib/libtiff.dll.a

% ls -l /usr/include/tiff*
-rwx--+   1 hb   None24302 Feb 10  2002
/usr/include/tiff.h
-rwx--+   1 hb   None 5254 Feb 10  2002
/usr/include/tiffconf.h
-rwx--+   1 hb   None14072 Feb 10  2002
/usr/include/tiffio.h
-rwx--+   1 hb   None11554 Feb 10  2002
/usr/include/tiffiop.h
-rwx--+   1 hb   None  410 Feb 10  2002
/usr/include/tiffvers.h

I appreciate any help. 

Cheers

Henrik Bengtsson



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: gcc and libtiff, maybe a newbie question

2003-01-02 Thread Elfyn McBratney
Hi,

The problem is partially due to where the -lname bits are. They should
be put at the end of the line (after all options and stuff). You also
needed to include libz (-lz) and libjpeg (-ljpeg).

This worked for me:

$ gcc -static -o tifft tifft.c -lm -ltiff -ljpeg -lz

P.s. I renamed your file to tifft.c, still using your code.

Elfyn
[EMAIL PROTECTED]


--- Henrik Bengtsson [EMAIL PROTECTED] wrote:
Hi, first I haven't done C programming in years and am a bit rusty with
gcc and ld. I am having problems with ld reporting undefined reference
to _TIFFOpen etc, which should be in libtiff. However, I am not even
sure if the problem is about libtiff or if miss something else.

Here is my minimize code I am trying to compile and link (write.c):

#include stdio.h
#include tiff.h
#include tiffio.h

int main(int argc, char *argv[]) {
  TIFF *image;

  if((image = TIFFOpen(output.tif, w)) == NULL){
printf(Could not open output.tif for writing\n);
exit(42);
  }
  TIFFClose(image);
}

I get the following error:
% gcc -static -lm -ltiff -o write.o -ltiff write.c
/tmp/ccfugoHj.o(.text+0x76):write.c: undefined reference to `_TIFFOpen'
/tmp/ccfugoHj.o(.text+0xa2):write.c: undefined reference to `_TIFFClose'
collect2: ld returned 1 exit status

According to the following troubleshooting it looks like it finds
libtiff.a (or something):
% gcc -static -lm -ltiffX -o write.o -ltiff write.c
/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../../i686-pc-cygwin/bin/ld:
cannot fi
nd -ltiffX
collect2: ld returned 1 exit status

According to Cygwin Setup the tiff version is 3.5.7-1. gcc is v3.2
(20020927). 

% ls -l /usr/lib/libtiff.*
-rwx--+   1 hb   None   316100 Feb 10  2002
/usr/lib/libtiff.a
-rwx--+   1 hb   None   152620 Feb 10  2002
/usr/lib/libtiff.dll.a

% ls -l /usr/include/tiff*
-rwx--+   1 hb   None24302 Feb 10  2002
/usr/include/tiff.h
-rwx--+   1 hb   None 5254 Feb 10  2002
/usr/include/tiffconf.h
-rwx--+   1 hb   None14072 Feb 10  2002
/usr/include/tiffio.h
-rwx--+   1 hb   None11554 Feb 10  2002
/usr/include/tiffiop.h
-rwx--+   1 hb   None  410 Feb 10  2002
/usr/include/tiffvers.h

I appreciate any help. 

Cheers

Henrik Bengtsson



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

_
www.smokeJet.com - Free UK Internet Services

_
Select your own custom email address for FREE! Get [EMAIL PROTECTED] w/No Ads, 6MB, 
POP  more! http://www.everyone.net/selectmail?campaign=tag

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: __RUNTIME_PSEUDO_RELOC_LIST[_END]__ (1.3.18-1)

2003-01-02 Thread Tim Prince

- Original Message -
From: Elfyn McBratney [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, January 02, 2003 4:04 PM
Subject: __RUNTIME_PSEUDO_RELOC_LIST[_END]__ (1.3.18-1)


 The pseudo reloc is a new addition to cygwin-1.3.18-1. Taken from the
 release announce
 (http://www.cygwin.com/ml/cygwin-announce/2002-12/msg00031.html)

   - Implement pseudo reloc code which now allows transparent linking
   of dlls similar to UNIX.  (Egor Duda)

 What problems are you experiencing? The symbols
 __RUNTIME_PSEUDO_RELOC_LIST__ and __RUNTIME_PSEUDO_RELOC_LIST_END__ are exported by 
binutils, so have you updated that recently?

I've been using a plain binary installation of the default cygwin binutils.  I would 
have thought that the default choice of
libcygwin.a ought to work with the default choice of binutils, absent instructions to 
do otherwise.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: 1.3.18-1: can't create title mutex was RE: Problem with Cygwin DLL 1.3.18-1 and CVS and SSH

2003-01-02 Thread Stephan Borchert
Hi,

i have the same error in another situation. And Ben Eng wrote me this E-Mail, that he 
has the same problem in W2K.

Stephan

 --- Original Message --- 

 Von : Ben Eng
 Datum : Thu, 2 Jan 2003 16:32:18 -0500

 i have an every time updated Cygwin installation. Last day's i
 updated my installtion and get the Cygwin DLL 1.3.18-1.
 
 I make every date an CVS update to an repository and have no
 errors. But with the new DLL i get this error:

 E:\cygwin\bin\ssh.exe: *** can't create title mutex, Win32 error 6
 cvs [update aborted]: end of file from server (consult above messages if any)

I am seeing this exactly problem on my Windows 2000 installation.

However, on Windows XP there is no problem at all.

I'm not on the cygwin mailing list, but if you could follow-up and let
them know that the problem appears to be Win2K-specific, I'd
appreciate it. Thanks.

Ben



_
Arcor-DSL Flatrate - jetzt kostenlos einsteigen und bis zu Euro 76,18 sparen!
Arcor-DSL gibt es jetzt auch mit bis zu 1500 Mbit/s Downstream!
http://www.angebot.arcor.net/cgi-bin/angebot.cgi?key=b13e92247022



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/


RE: gcc and libtiff, maybe a newbie question

2003-01-02 Thread Henrik Bengtsson
Vola, it works for me now. 

Thanks a lot and have really good day!

Henrik

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED]] On Behalf Of Elfyn McBratney
 Sent: den 3 januari 2003 17:53
 To: Henrik Bengtsson; [EMAIL PROTECTED]
 Subject: Re: gcc and libtiff, maybe a newbie question
 
 
 Hi,
 
 The problem is partially due to where the -lname bits are. 
 They should be put at the end of the line (after all options 
 and stuff). You also needed to include libz (-lz) and libjpeg 
 (-ljpeg).
 
 This worked for me:
 
 $ gcc -static -o tifft tifft.c -lm -ltiff -ljpeg -lz
 
 P.s. I renamed your file to tifft.c, still using your code.
 
 Elfyn
 [EMAIL PROTECTED]
 
 
 --- Henrik Bengtsson [EMAIL PROTECTED] wrote:
 Hi, first I haven't done C programming in years and am a bit 
 rusty with 
 gcc and ld. I am having problems with ld reporting 
 undefined reference 
 to _TIFFOpen etc, which should be in libtiff. However, I am 
 not even 
 sure if the problem is about libtiff or if miss something else.
 
 Here is my minimize code I am trying to compile and link (write.c):
 
 #include stdio.h
 #include tiff.h
 #include tiffio.h
 
 int main(int argc, char *argv[]) {
   TIFF *image;
 
   if((image = TIFFOpen(output.tif, w)) == NULL){
 printf(Could not open output.tif for writing\n);
 exit(42);
   }
   TIFFClose(image);
 }
 
 I get the following error:
 % gcc -static -lm -ltiff -o write.o -ltiff write.c
 /tmp/ccfugoHj.o(.text+0x76):write.c: undefined reference to 
 `_TIFFOpen'
 /tmp/ccfugoHj.o(.text+0xa2):write.c: undefined reference to 
 `_TIFFClose'
 collect2: ld returned 1 exit status
 
 According to the following troubleshooting it looks like it finds 
 libtiff.a (or something): % gcc -static -lm -ltiffX -o 
 write.o -ltiff 
 write.c
 /usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../../i686-pc-cygwi
 n/bin/ld:
 cannot fi
 nd -ltiffX
 collect2: ld returned 1 exit status
 
 According to Cygwin Setup the tiff version is 3.5.7-1. gcc is v3.2 
 (20020927).
 
 % ls -l /usr/lib/libtiff.*
 -rwx--+   1 hb   None   316100 Feb 10  2002
 /usr/lib/libtiff.a
 -rwx--+   1 hb   None   152620 Feb 10  2002
 /usr/lib/libtiff.dll.a
 
 % ls -l /usr/include/tiff*
 -rwx--+   1 hb   None24302 Feb 10  2002
 /usr/include/tiff.h
 -rwx--+   1 hb   None 5254 Feb 10  2002
 /usr/include/tiffconf.h
 -rwx--+   1 hb   None14072 Feb 10  2002
 /usr/include/tiffio.h
 -rwx--+   1 hb   None11554 Feb 10  2002
 /usr/include/tiffiop.h
 -rwx--+   1 hb   None  410 Feb 10  2002
 /usr/include/tiffvers.h
 
 I appreciate any help.
 
 Cheers
 
 Henrik Bengtsson
 
 
 
 --
 Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
 Bug reporting: http://cygwin.com/bugs.html
 Documentation: http://cygwin.com/docs.html
 FAQ:   http://cygwin.com/faq/
 
 _
 www.smokeJet.com - Free UK Internet Services
 
 _
 Select your own custom email address for FREE! Get 
 [EMAIL PROTECTED] w/No Ads, 6MB, POP  more! 
 http://www.everyone.net/selectmail? campaign=tag
 
 --
 
 Unsubscribe info:  
 http://cygwin.com/ml/#unsubscribe-simple
 Bug reporting: http://cygwin.com/bugs.html
 Documentation: http://cygwin.com/docs.html
 FAQ:   http://cygwin.com/faq/
 
 


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Re: __RUNTIME_PSEUDO_RELOC_LIST[_END]__ (1.3.18-1)

2003-01-02 Thread Elfyn McBratney
What we're you doing when these warning's came up? I guess the
compilation bit but what we're you compiling? Where you using dynamic
libraries? What compile line did you use?

Have you checked that you have the latest binutils? What's your
cygcheck output?

  run `cygcheck -s -v -r  cygcheck.out' and attatch that file,
  *non-compressed*.

Elfyn
[EMAIL PROTECTED]


--- Tim Prince [EMAIL PROTECTED] wrote:

- Original Message -
From: Elfyn McBratney [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, January 02, 2003 4:04 PM
Subject: __RUNTIME_PSEUDO_RELOC_LIST[_END]__ (1.3.18-1)


 The pseudo reloc is a new addition to cygwin-1.3.18-1. Taken from the
 release announce
 (http://www.cygwin.com/ml/cygwin-announce/2002-12/msg00031.html)

   - Implement pseudo reloc code which now allows transparent linking
   of dlls similar to UNIX.  (Egor Duda)

 What problems are you experiencing? The symbols
 __RUNTIME_PSEUDO_RELOC_LIST__ and __RUNTIME_PSEUDO_RELOC_LIST_END__ are exported by 
binutils, so have you updated that recently?

I've been using a plain binary installation of the default cygwin binutils.  I would 
have thought that the default choice of
libcygwin.a ought to work with the default choice of binutils, absent instructions to 
do otherwise.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

_
www.smokeJet.com - Free UK Internet Services

_
Select your own custom email address for FREE! Get [EMAIL PROTECTED] w/No Ads, 6MB, 
POP  more! http://www.everyone.net/selectmail?campaign=tag

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Updated Cygwin Package: python-2.2.2-4

2003-01-02 Thread Jason Tishler
New News:
=== 
I have updated the version of Python to 2.2.2-4.  The tarballs should be
available on a Cygwin mirror near you shortly.

The main purpose of this release is to rebuild the _tkinter module
against the latest Cygwin tcltk package.

Additionally, the _socket module is *no* longer built as a static module
to workaround a Cygwin fork() issue due to DLL base address conflicts.
Note that this workaround does not works with the current Cygwin
release.  Instead, if you are experiencing fork() failures, then you
must rebase your Cygwin system.  See the README for more details.

Old News:
=== 
Python is an interpreted, interactive, object-oriented programming
language.  If interested, see the Python web site for more details:
   
http://www.python.org/ 

Please read the README file:

/usr/doc/Cygwin/python-2.2.2.README

since it covers requirements, installation, known issues, etc.

To update your installation, click on the Install Cygwin now link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

Note that we have recently stopped downloads from sources.redhat.com
(aka cygwin.com) due to bandwidth limitations.  This means that you will
need to find a mirror which has this update.

In the US,
ftp://mirrors.rcn.net/mirrors/sources.redhat.com/cygwin/
is a reliable high bandwidth connection.

In Germany,
ftp://ftp.uni-erlangen.de/pub/pc/gnuwin32/cygwin/mirrors/cygnus/
is usually pretty good.

In the UK,
http://programming.ccp14.ac.uk/ftp-mirror/programming/cygwin/pub/cygwin/
is usually up-to-date within 48 hours.

If one of the above doesn't have the latest version of this package
then you can either wait for the site to be updated or find another
mirror.

The setup.exe program will figure out what needs to be updated on your
system and will install newer packages automatically.

If you have questions or comments, please send them to the Cygwin
mailing list at: [EMAIL PROTECTED] .  I would appreciate if you would
use this mailing list rather than emailing me directly.  This includes
ideas and comments about the setup utility or Cygwin in general.

If you want to make a point or ask a question, the Cygwin mailing list
is the appropriate place.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the List-Unsubscribe:  tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

[EMAIL PROTECTED]

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6