Re: [bug-inetutils] [Platform-testers] inetutils pre-release

[Simon Josefsson]

address@hidden (Alfred M. Szmidt) writes:

>    >> I rolled a pre-release of GNU InetUtils, please test it!
>    >> 
>    >> http://daily.josefsson.org/inetutils/inetutils-1.8.150-c548.tar.gz
>    >
>    > There was no statement where to send the reports to; I hope I'm right
>    > when sending this report to bug-inetutils.
>
>    Ah, sorry about that.  Yes bug-inetutils is fine.
>
> Maybe we should add a blurb at the end of ./configure?  This would
> make it easier for people to know where they should report bugs.

I doubt it -- that should be clear from README etc.  I suspect Bruno's
question was prompted by the instructions for posting to the
platform-testers probably said (or so I recall) that one should mention
which e-mail address to report problems to, and I didn't do that.

>    > * Linux MIPS
>    > I had two build running at the same time, one in 32-bit mode, one in 
> 64-bit
>    > mode. One succeeded, the other one failed:
>    >
>    > Desired port 7777/udp is already in use.
>    > FAIL: tftp.sh
>
>    Randomizing the ports is one solution, but there may still be issues if
>    the port is used.  Is there any reasonable way of finding an unused port
>    that isn't subject to race conditions?  Combining randomization (based
>    on PID), making sure the port is > 1024, together with a check to find
>    out whether the port is in use may be sufficient in practice.
>
> I have a ugly `port-open-p.c' program which I use to check if a port
> is open or not, but it isn't portable.  And as you say, it is prone to
> race conditions.  Though, I do not think we need to worry about them,
> a port being opened between testing and actually binding to it is
> miniscule.

Some solution is needed here though.  Meanwhile we could state that
parallel 'make check' runs are not supported.

>    > 
> ===============================================================================
>    >
>    > * AIX 5.1, OSF/1 5.1, Solaris 8
>    >
>    >   CC     hostname.o
>    > "hostname.c", line 93.25: 1506-045 (S) Undeclared identifier sethostname.
>    > "hostname.c", line 161.31: 1506-045 (S) Undeclared identifier 
> sethostname.
>    > make: 1254-004 The error code from the last command is 1.
>    >
>    > The function sethostname is not portable, see
>    > gnulib/doc/glibc-functions/sethostname.texi
>
>    Either hostname should return an error on these platforms, or it
>    shouldn't be built at all.  I'm mildly in favor of the first option
>    (there are other uses of hostname than setting the hostname).  Thoughts?
>    I'll implement the former unless if there are no objections.
>
> Please do.

I'll take a look.

>
>    > 
> ===============================================================================
>    >
>    > Cygwin 1.7.9
>    >
>    >   CC     tftpsubs.o
>    > tftpsubs.c:69:23: fatal error: arpa/tftp.h: No such file or directory
>    > compilation terminated.
>    > make[2]: *** [tftpsubs.o] Error 1
>    >
>    > The include file <arpa/tftp.h> does not exist on
>    > Minix 3.1.8, mingw, MSVC 9, BeOS, Haiku.
>
>    We could add a replacement arpa/tftp.h to gnulib, as a glibc-header?
>    The arpa/tftp.h on my systems comes from glibc, at least, even if it is
>    not documented in the glibc manual.
>
> This is a good idea.

Same here.

>    > 
> ===============================================================================
>    >
>    > mingw
>    >
>    > Link error while linking git-merge-changelog:
>    >
>    >   CCLD   git-merge-changelog.exe
>    > libgnu.a(getcwd.o): In function `rpl_getcwd':
>    > 
> /home/bruno/multibuild-1504/mingw2009/inetutils-1.8.150-c548/lib/getcwd.c:246:
>    > undefined reference to `_fdopendir'
>    > 
> /home/bruno/multibuild-1504/mingw2009/inetutils-1.8.150-c548/lib/getcwd.c:300:
>    > undefined reference to `_fstatat'
>    > collect2: ld returned 1 exit status
>    > make[4]: *** [git-merge-changelog.exe] Error 1
>    >
>    > Why is lib/git-merge-changelog.c part of the source code and
>    > built by default?
>
>    I've no idea -- unless there are objections, I'll remove
>    git-merge-changelog from bootstrap.conf.
>
> Can we conditionalize it? I use git-merge-changelog directly under the
> tree.  Or better yet, fix these undefined references?  Though, I am
> not objecting to removing git-merge-changelog from bootstrap.conf, but
> it would be nice to fix the root cause of the problem.

Bruno, shouldn't git-merge-changelog build for mingw?  Or is it not
intended to be a portable program?

I haven't seen any other project include git-merge-changelog, which
makes some sense as it seems to be more of a developer tool not strictly
related to building the project itself.

/Simon