[ADOPT] iperf 2.0.8
Tue Jul 14 11:34:00 GMT 2015
On 7/14/2015 10:27 AM, Joel Johnson wrote:
> On 2015-07-13 19:31, Joel Johnson wrote:
> I've put together an update for iperf, with no significant changes
> needed. I've done some consolidation into just the cygport file, and
> removed the override of src_compile as there were no special
> requirements and how it was neglected to do the cygautoreconf update step.
> I've also bumped to version 2.0.5. There is a fork (sourceforge project
> iperf2 instead of iperf) with releases to 2.0.8, but I'm not comfortable
> uploading that since one of the changelog entries is an incompatible
> change ("Require -u for UDP (-b no longer defaults to UDP)"). I'll
> follow-up with an ITP for iperf3 which I recommend having as a separate
> package (named iperf3 following Debian naming) since it isn't strictly
> Source change history:
build fine. Have you tested it?
on 64 bit I see
$ iperf -s -D
$ 1 [main] iperf 5396 fork: child -1 - forked process 9264 died
unexpectedly, retry 0, exit code 0xC0000005, errno 11
and 32bit strace...
--- Process 8552, exception 80000001 at 73006661
> As I'm new to cygwin packaging, I have a few questions (coming from a
> Debian slant):
> A) Is there a standard location for accessing source history of
> package files? I've put them on a github for the time being, is there a
> more appropriate location? I couldn't seem to find anything consistent
> for other packages.
no common source area for the time being.
Mine are on github also.
> B) What is the convention for line-wrapping on the ldesc in
> setup.hint, wrap or long lines?
> C) There doesn't seem to be a way in the path structure to have the
> x86 binary, x86_64 binary, and a shared source file, or am I missing
> D) When using setup.hint generation from the X.cygport file values,
> is there a way to specificy prev/current/test versions if needed?
There was a discussion, but I don't remind the outcome.
> E) Is the CYGWIN-PATCHES/README strictly required? There was one
> present previously, but I removed it since it didn't seem to add
> anything of value and was another file to track.
It is now optional.
> One issue that I did run into was in trying to use cygport to
> cross-compile from a x86 installation for a x86_64 target. I installed
> cygwin64, assuming that was in support of doing just that. It appeared
> to work until the actual compilation failing a lookup for rpl_malloc.
> Disabling the AC_FUNC_MALLOC check allowed it to succeed. Should the
> upload include a patch to disable that check, or is there some other
> package that I should have installed to make it work. I ended up doing a
> lean new 64-bit installation and the build went cleanly (as provided
> above), so it appears to be just a cross-compilation issue.
> Thanks for review and feedback!
More information about the Cygwin-apps