Re: gcc -mno-cygwin still wants to link with cygwin libs

[Brian Dessent]

Peter Amstutz wrote:

> However, the real problem is that when ld searches the linker path, it
> seems to do so in several phases, and is the way this search works is
> troublesome.  I should note that it does find files that end it ".lib",
> but only AFTER it has searched the ENTIRE path for files ending in
> ".dll.a".  What this means is that "libjpeg.dll.a" from cygwin, although
> at the very end of the search path, is found and matched before
> "jpeg.lib", which is at the very beginning of the search path, but the
> misfortune of having the wrong name and relegated to the second search
> pass.  It is discriminated against.  If I rename "jpeg.lib" to
> "libjpeg.dll.a", it finds the correct link library at the correct
> location.

The search order is documented:
.

My advice is just specify the filename of the library directly, without
flags, e.g. "/path/to/file.lib" and don't try to use -L or -l.  There
should be zero ambiguity if you do this.

> used by several different compilers, so I'm trying to avoid having to keep
> multiple copies around to work around this problem just because cygwin
> wants to be special.

Frankly I'm surprised that ld ever finds a file named foo.lib when you
specify -lfoo.  Cygwin's gcc is a part of the gnu toolchain and tries to
follow the same file naming conventions that the gnu toolchain uses on
all platforms.  And in that convention libraries end in .a.  It is most
certainly not "just being special".  You're trying to put a square peg
in a round hole mixing -lfoo and files named .lib, and I'm not surprised
that it doesn't work in ways that make sense.

You might as well ask Microsoft why their linker's default search rules
won't ever find an import library named ".dll.a" and see what their
response is.

Brian

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

gcc -mno-cygwin still wants to link with cygwin libs

[Peter Amstutz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello.  I am using the cygwin toolchain with to build a windows native app 
(using -mno-cygwin), but I've run into some library troubles, and I was 
hoping someone could offer some advice.


I have a library, jpeg.lib (and corrisponding dll).  It doesn't depend on 
cygwin and was probably compiled with msvc.


On my gcc link line, I supply -L/path/with/lib which has jpeg.lib.

However, when I look at the dependencies of the resulting binary, I find 
it has linked to cygwin's libjpeg from /usr/lib.  What's going on here?


Having spent an evening groveling over the output of ld --verbose, I have 
determined the cause of my woes, and I'd like to see if anyone has any 
suggestions as for what to do about it.


There are two problems here.

The first problem is that it is looking it /usr/lib at all.  Generally 
speaking, that directory is going to be populated with cygwin libraries, 
not mingw ones.  If you dip into the linker's call to collect2.exe, you'll 
see this:
   -L/usr/lib/gcc/i686-pc-mingw32/3.4.4/../../.. Which, if you disentangle 
that a bit, means it searches in /usr/lib.  Whether this is a bug or not 
is arguable ("broken by design" would seem to be a more accurate 
description), but it is very inconvenient.


However, the real problem is that when ld searches the linker path, it 
seems to do so in several phases, and is the way this search works is 
troublesome.  I should note that it does find files that end it ".lib", 
but only AFTER it has searched the ENTIRE path for files ending in 
".dll.a".  What this means is that "libjpeg.dll.a" from cygwin, although 
at the very end of the search path, is found and matched before 
"jpeg.lib", which is at the very beginning of the search path, but the 
misfortune of having the wrong name and relegated to the second search 
pass.  It is discriminated against.  If I rename "jpeg.lib" to 
"libjpeg.dll.a", it finds the correct link library at the correct 
location.


However, the rub is that this particular link library is intended to be 
used by several different compilers, so I'm trying to avoid having to keep 
multiple copies around to work around this problem just because cygwin 
wants to be special.


On unix this problem would be solved by symlinks.  Which might even work 
here too...  But it is pitfalls like this that drive people to use the 
otherwise horrendous MSYS toolkit, because of the quirks of Cygwin's mingw 
mode.


[   Peter Amstutz   ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED]  ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEiPn7aeHUyhjCHfcRArmRAJ9TNpgRR4SZ+aSK3mr+ya6WeoG0CQCePvrR
z58GmSpZtUyHyWPPlPot4Ko=
=XUun
-END PGP SIGNATURE-


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

docbook-xsl to 1.70.1 release?

[Steven Archuleta]

Would like to use the latest FOP extensions and would appreciate if the 
docbook-xsl pkg could be upgraded from 1.69.1 to the latest release 
(1.70.1).


Thanks,
Steve



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

Relating to randy freeman Thanks

[Raymundo Milton]

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

Re: cygwin non-posix problems

[Christopher Faylor]

On Thu, Jun 08, 2006 at 10:03:58PM -0400, Christopher Faylor wrote:
>On Thu, Jun 08, 2006 at 05:11:29PM -0700, Yitzchak Scott-Thoennes wrote:
>>Linda Walsh wrote:
>>> Yitzchak Scott-Thoennes wrote:
 Can he or you reduce the problem to a non-File::BOM dependent test
 script
>>> What part of the perl module File::BOM should I throw out before
>>> it's no longer File::BOM?  It's just perl code.
>>>
>>> It's freely downloadable through CPAN, so I can't make it too
>>> much more publicly available than that.
>>
>>The point would be to reduce the amount of code that might need
>>to be inspected to find the underlying problem.  Nothing to do
>>with publicly available.
>>
>>> But FWIW, the File::BOM code isn't the actual problem.  It's
>>> the authors test routine that he decided to be "fancy" with,
>>> and use a child process to send strings via a "FIFO" to the
>>> test harness process.
>>>
>>> It isn't desirable to modify "cygwin-only-failing" Perl modules
>>> to work around problems than only happen under cygwin.  Certainly
>>> you can see how that is "burying one's head under the sand".  Suppose
>>> various parts of CPAN are rewritten to steer around bugs in Cygwin.
>>> Does that make the underlying problems problems in Cygwin go away?
>>> Does that make cygwin more stable or more compatible with other
>>> Posix platforms?
>>>
>>> In my mind it eliminates test cases that are perfectly uncovering
>>> Cygwin incompatibilities and deficiencies.
>>
>>I agree with all of the above and wasn't trying to suggest modifying
>>the tests.
>
>Indeed, this is standard operating procedure for debugging problems.

In case this wasn't clear, I meant that winnowing down a failure to a
minimal amount of code required to reproduce the problem is "SOP".

cgf

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

Re: cygwin non-posix problems

[Christopher Faylor]

On Thu, Jun 08, 2006 at 05:11:29PM -0700, Yitzchak Scott-Thoennes wrote:
>Linda Walsh wrote:
>> Yitzchak Scott-Thoennes wrote:
>>> Can he or you reduce the problem to a non-File::BOM dependent test
>>> script
>> What part of the perl module File::BOM should I throw out before
>> it's no longer File::BOM?  It's just perl code.
>>
>> It's freely downloadable through CPAN, so I can't make it too
>> much more publicly available than that.
>
>The point would be to reduce the amount of code that might need
>to be inspected to find the underlying problem.  Nothing to do
>with publicly available.
>
>> But FWIW, the File::BOM code isn't the actual problem.  It's
>> the authors test routine that he decided to be "fancy" with,
>> and use a child process to send strings via a "FIFO" to the
>> test harness process.
>>
>> It isn't desirable to modify "cygwin-only-failing" Perl modules
>> to work around problems than only happen under cygwin.  Certainly
>> you can see how that is "burying one's head under the sand".  Suppose
>> various parts of CPAN are rewritten to steer around bugs in Cygwin.
>> Does that make the underlying problems problems in Cygwin go away?
>> Does that make cygwin more stable or more compatible with other
>> Posix platforms?
>>
>> In my mind it eliminates test cases that are perfectly uncovering
>> Cygwin incompatibilities and deficiencies.
>
>I agree with all of the above and wasn't trying to suggest modifying
>the tests.

Indeed, this is standard operating procedure for debugging problems.

>> Certainly, we can agree, that a process under cygwin should not
>> normally hang and be unresponsive to cygwin "kill -9" signals?
>
>/bin/kill -f worked for me.

That would suggest that File::BOM is using blocking windows calls
directly somehow.  Gee, if only there was some way to narrow this down.

I know! It must be because fork doesn't work on a multi-threaded dual
core processor!

cgf

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

Re: cygwin non-posix problems

[Yitzchak Scott-Thoennes]

Linda Walsh wrote:
> Yitzchak Scott-Thoennes wrote:
>> Can he or you reduce the problem to a non-File::BOM dependent test
>> script
> What part of the perl module File::BOM should I throw out before
> it's no longer File::BOM?  It's just perl code.
>
> It's freely downloadable through CPAN, so I can't make it too
> much more publicly available than that.

The point would be to reduce the amount of code that might need
to be inspected to find the underlying problem.  Nothing to do
with publicly available.

> But FWIW, the File::BOM code isn't the actual problem.  It's
> the authors test routine that he decided to be "fancy" with,
> and use a child process to send strings via a "FIFO" to the
> test harness process.
>
> It isn't desirable to modify "cygwin-only-failing" Perl modules
> to work around problems than only happen under cygwin.  Certainly
> you can see how that is "burying one's head under the sand".  Suppose
> various parts of CPAN are rewritten to steer around bugs in Cygwin.
> Does that make the underlying problems problems in Cygwin go away?
> Does that make cygwin more stable or more compatible with other
> Posix platforms?
>
> In my mind it eliminates test cases that are perfectly uncovering
> Cygwin incompatibilities and deficiencies.

I agree with all of the above and wasn't trying to suggest modifying
the tests.

> Another example is the Win32::API module?  It also
> fails under cygwin -- starting about 9 months ago.  Still does.  The
> problems in cygwin aren't going away.  And when module developers
> get bugs reported under cygwin, they may not bother with them if
> cygwin is known to have many Posix compatibility problems.

I didn't know posix compatibility problems were at issue there?
And I don't think posix compatibility ranks high in importance
for Win32::API.

> The module maintainers would like nothing more than for their module
> to work w/o problems on all platforms.  Perl goes to great lengths
> to ensure "it just works", "out-of-the-box" on scores of platforms.
>
> Also, FWIW, I did report a simpler test case that came up during
> their continued attempts to isolate the problem:
> ([perlbug #39325]: Cygperl allows reading of file descriptors open
> Write-Only)
>
> I don't know if the above bug is somehow the "root" cause of the
> problem in File::BOM but I doubt it is solely responsible for the
> behaviors I'm seeing, including cygperl hanging and being
> unkillable from within cygwin.
>
> Certainly, we can agree, that a process under cygwin should not
> normally hang and be unresponsive to cygwin "kill -9" signals?

/bin/kill -f worked for me.


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

Re: cygwin non-posix problems

[Linda Walsh]

Yitzchak Scott-Thoennes wrote:

Can he or you reduce the problem to a non-File::BOM dependent test script

What part of the perl module File::BOM should I throw out before
it's no longer File::BOM?  It's just perl code.

It's freely downloadable through CPAN, so I can't make it too
much more publicly available than that.

But FWIW, the File::BOM code isn't the actual problem.  It's
the authors test routine that he decided to be "fancy" with,
and use a child process to send strings via a "FIFO" to the
test harness process.

It isn't desirable to modify "cygwin-only-failing" Perl modules
to work around problems than only happen under cygwin.  Certainly
you can see how that is "burying one's head under the sand".  Suppose
various parts of CPAN are rewritten to steer around bugs in Cygwin.
Does that make the underlying problems problems in Cygwin go away?
Does that make cygwin more stable or more compatible with other
Posix platforms? 


In my mind it eliminates test cases that are perfectly uncovering
Cygwin incompatibilities and deficiencies.

Another example is the Win32::API module?  It also
fails under cygwin -- starting about 9 months ago.  Still does.  The
problems in cygwin aren't going away.  And when module developers
get bugs reported under cygwin, they may not bother with them if
cygwin is known to have many Posix compatibility problems.
The module maintainers would like nothing more than for their module
to work w/o problems on all platforms.  Perl goes to great lengths
to ensure "it just works", "out-of-the-box" on scores of platforms.

Also, FWIW, I did report a simpler test case that came up during
their continued attempts to isolate the problem:
([perlbug #39325]: Cygperl allows reading of file descriptors open 
Write-Only)


I don't know if the above bug is somehow the "root" cause of the
problem in File::BOM but I doubt it is solely responsible for the
behaviors I'm seeing, including cygperl hanging and being
unkillable from within cygwin.

Certainly, we can agree, that a process under cygwin should not
normally hang and be unresponsive to cygwin "kill -9" signals?

linda






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

Re: cygwin fork problem maybe?

[Linda Walsh]

Brian Dessent wrote:

Linda W wrote:

  

Windows just doesn't support forking at all, as far as I know.
activeperl emulates forking using win32 threads. I don'tknow how cygwin
handles it, but my guess is that it's not very well :-(



This smells like total FUD.  This person that admittedly does not use
Cygwin nor obviously know anything about Cygwin says that it's a fork
problem and that's that? 

=
   They don't have a windows machine to test with, but they
are trying to help pinpoint a problem that works under linux
and ActiveState, which seems like the most useful response
to date.  I can't give them a Windows machine or a cygwin
install to test with.  I can run the programs and report on
the results, and I can get a copy of the source to you that
fails.  Is there anything else I could do to be helpful?

:-)
Linda


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

RE: Issue with Find command on windows NT

[Vishwanath_Karthik]

 
Hi,
I tried using find I:\ -noleaf -print ,but I am getting the
same error .
Part of the error is as follows.

D:\usr\meta\boxster\boxster_UNITw2kMixednew\boxster_UNITw2kMixednew_0245
>find I:\ode.boxster_UNITw2kMixednew_0228 -noleaf -print
find: /cygdrive/i changed during execution of find (old inode number
-506580184,
 new inode number -509781400, filesystem type is system) [ref 1114]
find: /cygdrive/i changed during execution of find (old inode number
-500892152,
 new inode number -509781400, filesystem type is system) [ref 1114]


The same output on Windows 2K client is as follows

D:\>find H:\ode.boxster_UNITw2kMixednew_0227 -noleaf -print
H:\ode.boxster_UNITw2kMixednew_0227
H:\ode.boxster_UNITw2kMixednew_0227/boxster_UNITw2kMixednew_0227_DVT1471
41_1


Thanks and Regards,
Karthik



-Original Message-
From: Igor Peshansky [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 08, 2006 2:58 PM
To: Vishwanath, Karthik
Cc: cygwin@cygwin.com
Subject: Re: Issue with Find command on windows NT

On Thu, 8 Jun 2006, Vishwanath_Karthik wrote:

> Hi,
>  Find command not seems to be working on Network shares on only
> Windows NT.
>  On Windows 2K,Winodws XP and Windows 2003 it seems to be working
> fine.
>
>   The command issued was
>
>   find I:/TREEABC -print
>
>   where "I " is the mapped network drive.

Does "find /cygdrive/i/TREEABC -print" work any better?

>  On All other Windows except Windows NT It displays all the files
> under TREEABC directory recursively.
>
>  But on Windows NT it does not do that.
>
>  Is there any reason for such behavior .Can this be patched up so
> that it works on Windows NT too?

Just a WAG, but try "find I:/TREEABC -noleaf -print" -- you may be
running
into inode emulation problems on Windows NT.

Otherwise, please read and follow the Cygwin problem reporting
guidelines
at .  There was also a message on this
list from Corinna Vinschen[1] with a program you could build and run on
your system to print the detailed network drive information -- that
might
be helpful in diagnosing the problem.
HTH,
Igor
[1] 
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] |
[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name
changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends
compte."
"But no -- you are no fool; you call yourself a fool, there's proof
enough in
that!" -- Rostand, "Cyrano de Bergerac"

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

Re: Issue with Find command on windows NT

[Igor Peshansky]

On Thu, 8 Jun 2006, Vishwanath_Karthik wrote:

> Hi,
>  Find command not seems to be working on Network shares on only
> Windows NT.
>  On Windows 2K,Winodws XP and Windows 2003 it seems to be working
> fine.
>
>   The command issued was
>
>   find I:/TREEABC -print
>
>   where "I " is the mapped network drive.

Does "find /cygdrive/i/TREEABC -print" work any better?

>  On All other Windows except Windows NT It displays all the files
> under TREEABC directory recursively.
>
>  But on Windows NT it does not do that.
>
>  Is there any reason for such behavior .Can this be patched up so
> that it works on Windows NT too?

Just a WAG, but try "find I:/TREEABC -noleaf -print" -- you may be running
into inode emulation problems on Windows NT.

Otherwise, please read and follow the Cygwin problem reporting guidelines
at .  There was also a message on this
list from Corinna Vinschen[1] with a program you could build and run on
your system to print the detailed network drive information -- that might
be helpful in diagnosing the problem.
HTH,
Igor
[1] 
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

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

Issue with Find command on windows NT

[Vishwanath_Karthik]

Hi,
 Find command not seems to be working on Network shares on only
Windows NT.
 On Windows 2K,Winodws XP and Windows 2003 it seems to be working
fine.


  The command issued was

  find I:/TREEABC -print
 
  where "I " is the mapped network drive. 
  
 On All other Windows except Windows NT It displays all the files
under TREEABC directory recursively.

 But on Windows NT it does not do that.


 Is there any reason for such behavior .Can this be patched up so
that it works on Windows NT too?



  Thanks and Regards,
   Karthik

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

Re: apache2 reports bad system call

[Larry Hall (Cygwin)]

Reformatted top-post.


Larry Hall (Cygwin) wrote:

Robert Khachikyan wrote:

Hi,

I successfully have installed and have been using cygwin on my 
windows XP.
Just recently I decided to add a web server. After installing the 
apache2,

it complains of 'Bad system call':

[EMAIL PROTECTED] /etc/apache2
$ /usr/sbin/httpd2.exe
Bad system call

[EMAIL PROTECTED] /etc/apache2
$ /usr/sbin/httpd2.exe -v
Server version: Apache/2.2.2
Server built:   Jun  6 2006 13:28:20


However, when starting the apache1.3.33, I have no problem. But due 
to security,
I'd like for the apache to be up-to-date.You guys have any 
suggestions?thanx



Read the readme?  Sounds to me like apache2 requires IPC via Cygserver.
I would think the readme would talk about this (don't have apache2 
installed
myself so I don't know for sure but then again Max is a pretty 
thorough guy).

If you're looking for more info on Cygserver, see:




Robert Khachikyan wrote:
> Initially when I installed sshd, it was said to have the CYGWIN
> environment variable to 'ntsec'.
>
> After reading your forwarded link, I switched it to 'server' and it runs
> ok now...thanx...


"ntsec" is the default and has been for some time.  Adding it to the CYGWIN
environment variable pretty much is only useful for "documentation" purposes
but adding it causes no harm either.  However, in case there's any confusion,
it is possible and permissible to add more than 1 option to the CYGWIN
environment variable.


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

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

Problems installing Apache 2.2 and mod_fastcgi

[Henry S. Thompson]

Since this took a modest amount of searching and trial and error, I
thought it might be worth reporting to others the steps that I've
taken to get fastcgi to compile and install, but not, alas, to work
completely, and ask for help at the end.

1) Using Cygwin Setup, install the following packages:

   apache2
   apache2-devel
   apr1
   aprutil1
   libdb4.2
   libdb4.2-devel
   libtool

2) Download and unpack
http://www.fastcgi.com/dist/mod_fastcgi-SNAP-0404142202.tar.gz

3) Apply the patches at
http://www.fastcgi.com/archives/fastcgi-developers/2005-December/004060.html
   e.g. by the following steps:

> wget 
http://www.fastcgi.com/archives/fastcgi-developers/2005-December/004060.html
> tail +55 004060.html | head -52 | sed 's/&/\&/g' > ap22.patch
> patch -p 1 < ap22.patch

4) Copy Makefile.AP2 to Makefile and apply the patch attached at the
   end of this email.

5) Make and install with

> make
> make install

7) Edit /etc/apache2/httpd.conf to add

LoadModule fastcgi_module lib/apache2/mod_fastcgi.so

8) Make sure cygserver is running

 See /usr/share/doc/Cygwin/cygserver.README for instructions

9) Launch your server

 > CYGWIN=server /usr/sbin/httpd2

That gets things running OK, but only using the external server option
(e.g.  FastCgiExternalServer /srv/www/cgi-bin/test.fcg -host localhost:6789) 

I can't get any FastCGI apps to operate in either normal (dynamic) or
static (using explicit TCP ports) mode -- I've tried the fast-cgi
examples from http://fastcgi.com/dist/fcgi.tar.gz and the trivial test
include with the Perl FCGI module, as well as an attempt to roll my
own using the thfcgi Python package.  When run dynamically they all
launch the app OK, but then all fail with one version or another of
'connection refused' or 'software caused connection abort' when the
first message is attempted to be sent from the apache2 server to the
app.  When run statically using TCP, they all die with "Address
already in use", because the Apache server still has the relevant port
open.

 Cygwin DLL version info:
DLL version: 1.5.19
DLL epoch: 19
DLL bad signal mask: 19005
DLL old termios: 5
DLL malloc env: 28
API major: 0
API minor: 150
Shared data: 4

If anyone can diagnose my problem, either be pointing out a mistake in
the build sequence above, or . . ., I'd be _most_ grateful.

ht

mk.patch==
--- Makefile~2006-06-07 16:57:14.796875000 +0100 
+++ Makefile2006-06-07 17:25:14.15625 +0100 
@@ -4,19 +4,20 @@ 
 
 builddir = .
 
-top_dir  = /usr/local/apache2
+top_dir  = /usr/share/apache2
 
 top_srcdir   = ${top_dir}
 top_builddir = ${top_dir}
 
 include ${top_builddir}/build/special.mk
 
-APXS  = apxs
-APACHECTL = apachectl
+APXS  = apxs2
+APACHECTL = apachectl2
 
 #DEFS=-Dmy_define=my_value
 #INCLUDES=-Imy/include/dir
 #LIBS=-Lmy/lib/dir -lmylib
+AP_LIBS=-lapr-1 -laprutil-1 -lhttpd2core
 
 all: local-shared-build
 
==
-- 
Henry S. Thompson, Markup Systems Ltd.
4 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- +44 (0) 7866 471 388
   Fax: (44) 131 650-4587, e-mail: [EMAIL PROTECTED]
URL: http://www.markup.co.uk/
[mail really from me _always_ has this .sig -- mail without it is forged spam]

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

Re: Problems installing Apache 2.2 and mod_fastcgi

[Henry S. Thompson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

ht writes:

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


Well, _that_ was unhelpful.

Will get my other persona to try again.

ht
- -- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
 Half-time member of W3C Team
2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: [EMAIL PROTECTED]
   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFEiFw2kjnJixAXWBoRAr1oAJ9gJ6KLgS0MwxmB3bXJfYFtTrCAcACePrx2
4oWTkAjekcG1etEa98OAYmU=
=m1+P
-END PGP SIGNATURE-

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

Re: UNIX Network Programming (unpve13e) make failing (AF_INET6 undeclared).

[mwoehlke]

Williams, Gerald S (Jerry) wrote:

Huw wrote:

The next issue I have is:

mcast_leave.c: In function `mcast_leave_source_group':
mcast_leave.c:78: error: storage size of 'mreq' isn't known


I don't know anything about the ip_mreq_source structure,
but it looks to me like the current version may be having
general issues with support for various platforms and
configurations.


Right. One of our products was defining it for the longest time, and 
suddenly it started breaking on Linux, so it seems like it's very spotty 
whether or not the OS will define this structure. RHEL3 doesn't seem to 
have it, but FC4 does. So does Solaris 10 (x86, anyway), but not Solaris 
9 (sparc). My copy of Cygwin seems to have it, but only in 
.


--
Matthew
Who let the hippos out?


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

Package READMEs on-line? (Was Re: apache2 reports bad system call)

[Igor Peshansky]

On Thu, 8 Jun 2006, Larry Hall (Cygwin) wrote:

> I would think the readme would talk about this (don't have apache2
> installed myself so I don't know for sure but then again Max is a pretty
> thorough guy).

I think it's time to re-iterate my proposal of having the package
Cygwin-specific READMEs (those in /usr/share/doc/Cygwin) extracted to some
place on the web (a separate directory on the mirrors, perhaps?).  Does
this sound feasible?  Would it make sense to do this?

CGF, I know upset is no longer publically available, but if you send me
the source, I could submit a patch that does this.  Once these are
on-line, it might also make sense to change the package search script to
make README files into links to their on-line locations on the sourceware
site.

And, just to put this in the archives again, having a database of package
release announcements somewhere on-line (keyed by version, so setup could
link to them) would also be helpful.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

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

RE: UNIX Network Programming (unpve13e) make failing (AF_INET6 undeclared).

[Williams, Gerald S \(Jerry\)]

Huw wrote:
> The first issue was an omission of #defines.  IPv6 isn't a
> necessity for the UNP source, I believe.

I'd say the real issue is a failure to protect the use of
AF_INET6. You'll notice that it's protected by an #ifdef
earlier.

> The next issue I have is:
> 
> mcast_leave.c: In function `mcast_leave_source_group':
> mcast_leave.c:78: error: storage size of 'mreq' isn't known

I don't know anything about the ip_mreq_source structure,
but it looks to me like the current version may be having
general issues with support for various platforms and
configurations.

Have you tried using the version at www.kohala.com (i.e.,
unpv12e)? That was the the last one that Richard Stevens
wrote. At least the "lib" directory seems to build OK for
me. Even if you really want the latest library, looking
at the older code may help you with the port.

I haven't looked into the new version of that book, but
the new authors certainly had big shoes to fill.

gsw

P.S. www.kohala.com seemed to have intermittent access
problems (at least for me), so be patient.

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

Problems installing Apache 2.2 and mod_fastcgi

[Henry S. Thompson]

--- Makefile~2006-06-07 16:57:14.796875000 +0100 
+++ Makefile2006-06-07 17:25:14.15625 +0100 
@@ -4,19 +4,20 @@ 
 
 builddir = .
 
-top_dir  = /usr/local/apache2
+top_dir  = /usr/share/apache2
 
 top_srcdir   = ${top_dir}
 top_builddir = ${top_dir}
 
 include ${top_builddir}/build/special.mk
 
-APXS  = apxs
-APACHECTL = apachectl
+APXS  = apxs2
+APACHECTL = apachectl2
 
 #DEFS=-Dmy_define=my_value
 #INCLUDES=-Imy/include/dir
 #LIBS=-Lmy/lib/dir -lmylib
+AP_LIBS=-lapr-1 -laprutil-1 -lhttpd2core
 
 all: local-shared-build
 



-- 
		Henry S. Thompson, Markup Systems Ltd.
4 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- +44 (0) 7866 471 388
	   Fax: (44) 131 650-4587, e-mail: [EMAIL PROTECTED]
			URL: http://www.markup.co.uk/
[mail really from me _always_ has this .sig -- mail without it is forged spam]

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

Re[2]: Gdb and debug symbol in pdb

[Sergey Tovpeko]

> Perhaps implicit in Brian's response, there is little incentive for
> anyone to do this, since generation of .pdb by open source compilers
> will not be permitted.  The obstacles to full functioning of .pdb with
> commercial 3rd party compilers are high enough.

Certanly! .pdb doesn't documented very well :-). Moreover, microsoft
changes its internal structures from version to version.

But, my point is to use gdb as alternative to microsoft windbg. In my case
I prefer GDB because of its open standards. Also I suppose GDB has
enough functionality to write something like extenstions, macroses to
enhance the specific analysis.

Sergey.



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

Re: Gdb and debug symbol in pdb

[Tim Prince]

Brian Dessent wrote:

Sergey Tovpeko wrote:


I've a question about using gdb on windows. I'm debugging a
program produced by Microsoft compiler. It would be nice of GDB
to understand debug symbols in Microsoft-specific debug format (PDB).
Did anyone try to support this format in gdb? I know, it's private.
But Microsoft provides a big API for analyzing pdb format.


No, to my knowledge no one has ever tried to support PDB format in gdb. 
It sounds like an extremely non-trivial undertaking.  It would not just

be a matter of reading an undocumented file format.  Gdb would have to
be taught all the details of the MSVC C++ ABI -- name mangling, vtable
layout, and so on.  I suppose you could just support C only, but that
would make it useless for a great deal of code.

And on top of that the people who develop gdb are also those who
probably have the least desire to use MS proprietary compilers, as they
tend to have a stake in the gnu toolchain anyway. 
Perhaps implicit in Brian's response, there is little incentive for 
anyone to do this, since generation of .pdb by open source compilers 
will not be permitted.  The obstacles to full functioning of .pdb with 
commercial 3rd party compilers are high enough.


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

Re: Gdb and debug symbol in pdb

[Brian Dessent]

Sergey Tovpeko wrote:

> I've a question about using gdb on windows. I'm debugging a
> program produced by Microsoft compiler. It would be nice of GDB
> to understand debug symbols in Microsoft-specific debug format (PDB).
> Did anyone try to support this format in gdb? I know, it's private.
> But Microsoft provides a big API for analyzing pdb format.

No, to my knowledge no one has ever tried to support PDB format in gdb. 
It sounds like an extremely non-trivial undertaking.  It would not just
be a matter of reading an undocumented file format.  Gdb would have to
be taught all the details of the MSVC C++ ABI -- name mangling, vtable
layout, and so on.  I suppose you could just support C only, but that
would make it useless for a great deal of code.

And on top of that the people who develop gdb are also those who
probably have the least desire to use MS proprietary compilers, as they
tend to have a stake in the gnu toolchain anyway.  Besides, there are
already plenty of debuggers that understand PDB, both Microsoft and
third party, so it would be reinventing a wheel.

You might want to have this discussion on the gdb list, though I'm sure
it's come up before.

Brian

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

Gdb and debug symbol in pdb

[Sergey Tovpeko]

Hi, folks!

I've a question about using gdb on windows. I'm debugging a
program produced by Microsoft compiler. It would be nice of GDB
to understand debug symbols in Microsoft-specific debug format (PDB).
Did anyone try to support this format in gdb? I know, it's private.
But Microsoft provides a big API for analyzing pdb format.

And sorry for my english.
Thanks.





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

[ANNOUNCEMENT] Updated: rxvt-20050409-3

[Charles Wilson]

RXVT is a VT102 terminal emulator for both X and Windows.

This is a bugfix update (as was the -2 release, which I neglected to 
announce).  This release should correct the issues with 
font-size-changing in native windows mode, reported

   http://cygwin.com/ml/cygwin/2006-05/msg00967.html
   http://cygwin.com/ml/cygwin/2006-06/msg00109.html
   http://cygwin.com/ml/cygwin/2006-06/msg00124.html
Thanks to Gilbert, Cheetah, and rene.

The -2 release fixed an issue where rxvt would hide a user's interactive 
bash-in-cmd.exe session.



Changes since 20050409-2:
-
* Implement XTranslateCoords() within libW11 in an attempt to get
  smart resizing to work.  Discover that most Xservers lie about
  upper-left-corner position of client windows, such that WM decorations
  are already accounted for -- and thus the small section rxvt code
  within the smart-resize function that "compensates" for WM decorations
  is not  active with "real" Xservers.

  But libW11 doesn't lie about WM decorations.And rxvt's "compensation"
  code -- active in this case -- is hopelessly broken.

  Don't use --enable-smart-resize.

Changes since 20050409-1:
-
* Removed hide_console code.  As it happens, the W11 wrapper
  library already had similar -- smarter -- code for hiding
  the console.  This pre-existing code did not hide the console
  rxvt was invoked via a bash-in-cmd.exe shell, whereas the now-removed
  code did do so.  Thus, invoking 'rxvt' from the command line in such
  a shell permanently hid the user's existing session.  This was bad.
* However, this means we will need a different solution for when we
  invoke rxvt via a script and WANT the script's console hidden.
  See http://cygwin.com/ml/cygwin/2006-05/msg00403.html
* Turned on support for 24bit visuals (may only have effect when in
  X mode), as well as selection scrolling.

--
Chuck

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

1.5.19: SSH fails after cluster failover on Windows 2003

[Sean Pham]

I have ssh3.9p1 running on 2 cluster node connected to a direct shared
storage.  If I failover all the resource to the other node, sshd will
immediately fail.  I have replicated this multiple so I don't believe
that is a coincidence.  If I restart the node that ssh currently does
not work, sshd will start working again.  

I noticed that when failover completes, all the shared disk are now
listed as local disk and are inaccessible.   When I reboot, these disk
will go away.  This is common scenario with Windows during a failover
but is sshd expecting these disks to be online and tries to mount it? 

This is my first email in the group.  Please direct me or give me
instructions to what's the proper manner to request help.  I've attached
the cygcheck.out file.  

--sean





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

visualization app crashing on non build host

[Richard Beare]

Hi,

I've built two medical visualization tools (register and Display from
MNI, Mcgill) under cygwin. These tools both use opengl, glut, netcdf
and a couple of MNI developed libraries. They both build and run on my
cygwin machine. However when I move to other hosts, Display fails
immediately with a stackdump while register seems to work fine. When
installing on other hosts I'm including cygwin1.dll and glut32.dll in
the same directory as the applications. I haven't found any reference
to this sort of problem, but suspect that I might be missing something
simple.

Does anyone have suggestions?

Thanks in advance.


All the test hosts are running XP pro. The libraries reported by cygcheck are:

$ cygcheck ./Display.exe

.\Display.exe
 C:\cygwin\bin\cygwin1.dll
   C:\WINDOWS\system32\ADVAPI32.DLL
 C:\WINDOWS\system32\ntdll.dll
 C:\WINDOWS\system32\KERNEL32.dll
 C:\WINDOWS\system32\RPCRT4.dll
 C:\cygwin\bin\glut32.dll
   C:\WINDOWS\system32\USER32.dll
 C:\WINDOWS\system32\GDI32.dll
   C:\WINDOWS\system32\WINMM.dll
   C:\WINDOWS\system32\GLU32.dll
 C:\WINDOWS\system32\msvcrt.dll
 C:\WINDOWS\system32\OPENGL32.dll
   C:\WINDOWS\system32\DDRAW.dll
 C:\WINDOWS\system32\DCIMAN32.dll

$ cygcheck  ./register.exe

.\register.exe
 C:\cygwin\bin\cygwin1.dll
   C:\WINDOWS\system32\ADVAPI32.DLL
 C:\WINDOWS\system32\ntdll.dll
 C:\WINDOWS\system32\KERNEL32.dll
 C:\WINDOWS\system32\RPCRT4.dll
 C:\cygwin\bin\glut32.dll
   C:\WINDOWS\system32\USER32.dll
 C:\WINDOWS\system32\GDI32.dll
   C:\WINDOWS\system32\WINMM.dll
   C:\WINDOWS\system32\GLU32.dll
 C:\WINDOWS\system32\msvcrt.dll
 C:\WINDOWS\system32\OPENGL32.dll
   C:\WINDOWS\system32\DDRAW.dll
 C:\WINDOWS\system32\DCIMAN32.dll

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

Re: dialog/Xdialog or substitution in Cygwin ?

[Thorsten Kampe]

* LiuYan (2006-06-06 16:42 +)
> Is there a dialog and/or Xdialog package release in cygwin ?
> If not, can I found a substitution of it  or will it be migrated to cygwin ?

It compiles under Cygwin. So just "migrate" it yourself.


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

Re: Cygwin and Windows Vista Beta 2 (FAQ alert)

[Christopher Faylor]

On Thu, Jun 08, 2006 at 12:01:01AM -0400, Robert Pendell wrote:
>Maybe someone can offer to fix this now that Vista has gone into the
>public beta phase.  I can post links here if someone asks for them.

It's extremely unlikely.  We don't usually try to get Cygwin working on
moving targets.  We have enough trouble with the stationary ones.

The Cygwin web page says this:

"The Cygwin DLL works with all non-beta, non "release candidate", ix86
32 bit versions of Windows since Windows 95, with the exception of
Windows CE."

I guess this belongs as a FAQ entry as it comes up every time Microsoft
has a new beta.

Btw, what this means is that I normally ignore complaints about Cygwin
not working on beta versions of Windows.  I can't testify for Corinna,
however.  In know that in some rare occasions a Red Hat customer might
have an interest and will pay to get something working but this is not
a common occurrence.

cgf

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

Re:

[Larry Hall (Cygwin)]

Reformatted top-post.


Larry Hall (Cygwin) wrote:

Maurice Hüllein wrote:
I'm currently developing a c++ plugin for a windows simulator 
environment, which accepts plugins in form of a dll. For doing so my 
dll needs to include a library of this simulator program which is 
only supported
in ".a" format. I solved this problem by cross compiling the dll from 
cygwin for the windows platform.


But now there is another problem. My .dll-project needs to use 
external libraries which are only supported
in windows .lib format. So theres the issue that my VC Express 
compiler can not use the .a library and the
cross compiler can not handle the .lib. I already read that even if 
both, the .a and .lib, are static libraries there are 
incompatibilities because of the used compiler.
I would prefer to disclaim the bypass of using cygwin and a cross 
compiler at all. So is there any way of

converting the .a library in a native windows .lib?



The incompatibilities you refer to are the result of differences in 
different

"vendors" C++ formats, not in the differences between library formats.
Actually a static .a and .lib have the same format.  But the former
restriction overshadows the latter non-issue.  You'll need to wrap your
library in C-callable interfaces if you really want to get this to work.
Perhaps the very recently update SWIG library will be helpful for you?

Serethos wrote:
> Thx for your answer. But I called the guys from the SWIG mailing list
> and they stated that
> my problem can not be solved with SWIG. It would only be useful if I
> wished to use a
> e.g. c-program for another language.
> Any other ideas?
>

Off the top of my head, no.  Well, other than manually creating C-callable
interfaces yourself.  But I'll bet there's a project out there that would
help you do this if you poke around.

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

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