This is the mail archive of the
mailing list for the Cygwin project.
Re: Cygwin TCP slow
On 2016-11-30 07:49, Lee wrote:
>> If you also provided a Cygwin port of iperf3
> Any hints on how to do that?
If you are running under Cygwin, first install cygport (and let setup
install all its dependencies), and any iperf3 dependencies, then read
the cygport html doc, and create a minimal package .cygport file (or
download iperf source package and modify its .cygport for iperf3).
It defaults to build with autotools, so not much more needs to be
done if that is used.
Otherwise you may have to inherit one or more other cygclasses,
or modify default high level shell functions to override the
behaviour, obeying the rules about which directory variables to use
and in which to perform work.
If you only have Linux, you will have to check the setup.ini entry
for cygport and install it and the appropriate (cross) tools,
packages, and libraries, and the same for iperf3, for the host/target
Check the Source*Ware* cygwin-apps and Source*Forge*
cygwin-ports-general mailing lists archives, also available on
mail-archive.com and other ml mirrors, for more info on cygports and
> Trying to build using the i686-w64-mingw32-gcc cross-compiler dies
> because nanosleep is missing. How to figure out what needs to be
> installed to get that function?
> $ ./configure --prefix=/usr/local --build=i686-pc-cygwin
> <.. snip ..>
> checking for ANSI C header files... (cached) yes
> checking for library containing floor... none required
> checking for library containing nanosleep... no
> nanosleep() required for timing operations.
For nanosleep, there appear to be two different interfaces in time.h,
depending on whether _POSIX_TIMERS or _POSIX_CLOCK_SELECTION are
defined: check the .h for which interface is used and set the
appropriate definition to a POSIX release date e.g. 200809L.
The headers, newlib, and gcc support a variety of standards and
flavours of platform extensions, not all of which are compatible.
> Trying to build using the cygwin gcc compiler does because of
> "conflicting types for 'iprintf'"
> aside: Why would one redefine a standard routine instead of making
> their own routine that calls the standard routine?? The conflicting
> bit is in iperf_api.h:
> /* Custom printf routine. */
> int iprintf(struct iperf_test *test, const char *format, ...)
> __attribute__ ((format(printf,2,3)));
> In any case, how does one reconcile
> int iprintf( ...
> int _EXFUN(iprintf, ( ...
Original iperf predates POSIX additions, and they did not heed the C
and POSIX standards notes to avoid defining functions containing
One strategic #define iprintf iperf_printf in the right app header,
included after all standard headers, before other app headers, may
fix things up, or you may have to dink around with #undefs as well to
If your source defines no specific feature test macros, and you
compile with no standard language version, or a gnu version, _GNU_SOURCE
and many POSIX and glibc-compatible interfaces to newlib will be defined.
The same header may be included in the builds of the Windows cygwin
dll, the newlib library for Cygwin and many embedded platforms, tools
for many host platforms, and apps for many target platforms, so there
are macros which provide the appropriate decorations depending on
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple