netinet/tcp.h

netinet/tcp.h

[Robinow, David]

 I've just compiled the lastest Python beta 1.6b1 under Cygwin 1.1.4
It builds out of the box except for 2 things:
 1) the ".exe" suffix problem which has existed for a while and requires
    patching two files. (Partial support for solving this exists and I've
    submitted a patch for finishing this up.)

 2) Modules/socketmodule.c  has a statement
    #include <netinet/tcp.h>

    This file does not exist in Cygwin.  However, if I do:
       touch /usr/include/netinet/tcp.h

    The build completes and the test_socket test completes successfully.
    (A few other tests fail. I'm still investigating those.)
    Apparently whatever "normal" unix systems tend to put in
    netinet/tcp.h is handled elsewhere in Cygwin.

    My question is:
      Would it be reasonable for Cygwin to include an empty copy of this
    file so that packages that assume it is necessary can compile
succesfully?


David Robinow
 

Re: netinet/tcp.h

[Chris Faylor]

On Fri, Sep 01, 2000 at 01:44:20PM -0400, Robinow, David wrote:
> 2) Modules/socketmodule.c  has a statement
>    #include <netinet/tcp.h>
>
>    This file does not exist in Cygwin.  However, if I do:
>       touch /usr/include/netinet/tcp.h
>
>    The build completes and the test_socket test completes successfully.
>    (A few other tests fail. I'm still investigating those.)
>    Apparently whatever "normal" unix systems tend to put in
>    netinet/tcp.h is handled elsewhere in Cygwin.
>
>    My question is:
>      Would it be reasonable for Cygwin to include an empty copy of this
>    file so that packages that assume it is necessary can compile
>succesfully?

Hmm.  That's a reasonable suggestion.  I wonder if it would be more useful
to just have the file contain an:

#include <winsock.h>

though.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: netinet/tcp.h

[Norman Vine]

Hi David,

I've been building Python with Cygwin for years :-)

In fact I am the one that got the partial support for Cygwin
built into the Python make system originally.

At the time Guido did not want to add 'too' many special cases
to the configure.in script so we left it so that all one had to do for 
Cygwin was

export EXE='.exe'
before running configure
and this would set up the makefiles correctly :-)

FWIW IMHO
Rather then changing the Cygwin distribution to have
an empty header file which might break other applications
in strange ways.  This patch should be added to the 

// Python socketmodule.c 
#if !defined(__BEOS__) && !defined(__CYGWIN__)
#include <netinet/tcp.h>
#endif

FWIW  except for the select module will never run on win95/98
threads is the only module I have not got working and now that 
I can compile the Cygwin source I am working on that one :-)

I can send you a diff of my sources vs the current Python CVS
if you would like

Cheers

Norman Vine



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: netinet/tcp.h

[Robinow, David]

 
> I've been building Python with Cygwin for years :-)
> 
> In fact I am the one that got the partial support for Cygwin
> built into the Python make system originally.
> 
> At the time Guido did not want to add 'too' many special cases
> to the configure.in script so we left it so that all one had 
> to do for 
> Cygwin was
> 
> export EXE='.exe'
> before running configure
> and this would set up the makefiles correctly :-)
> 
> FWIW IMHO
> Rather then changing the Cygwin distribution to have
> an empty header file which might break other applications
> in strange ways.  This patch should be added to the 
> 
> // Python socketmodule.c 
> #if !defined(__BEOS__) && !defined(__CYGWIN__)
> #include <netinet/tcp.h>
> #endif
  I don't like this at all. When I see a lot of #ifdef for a
particular OS, I get the feeling that that OS is somehow
defective. I think I'm not the only one.  Also, your patch
fixes Python, which is nice, but what about the next Unix
app that wants to run on Cygwin?
  The reason I posted to this list is that I'd like Cygwin
to be successful.  That means making it as easy as possible
to "port" software. ("port" is in quotes because the best port
is no port at all.)
  I know very little about sockets under either Windows or Unix.
I have no idea if my suggestion is good.  I have a hunch Chris
is on the right track with #include <winsock.h> but I'm not
qualified to say.
 
> FWIW  except for the select module will never run on win95/98
> threads is the only module I have not got working and now that 
> I can compile the Cygwin source I am working on that one :-)
 Yes, select hangs forever on win98. I found that out last night
on my home machine.
 I failed math due to the "rint" bug that was reported here a
while back. Was this fixed in a recent Cygwin snapshot? I'm still
running release 1.1.4
 I also failed on strftime. I seem to remember somebody posting
about a problem with that on this list, but I thought the answer
was that they were using it wrong. Maybe Python is too?
> I can send you a diff of my sources vs the current Python CVS
> if you would like
 Do you have tkinter working?  I haven't tried any Setup changes.
Just the default. If you've done anything that's hard I'd be
interested. But better to post to comp.lang.python so others can
benefit.
 Suggestions for improvement to Cygwin can go here.

RE: netinet/tcp.h

[Joost Kraaijeveld]

> FWIW IMHO
> Rather then changing the Cygwin distribution to have
> an empty header file which might break other applications
> in strange ways.  This patch should be added to the 
I do not agree. I use a package (PostgreSQL 7.02) that also needs that file
and in the PostgreSQL is an empty file distributed, together with the
instruction to put it in the correct directory, so that configure and
compile work. I favor a empty tcp.h file added to cygwin, maybe with a
winsock.h included.

Joost

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com