bug-inetutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alfred M. Szmidt
Subject: Re: [bug-inetutils] [Platform-testers] inetutils pre-release
Date: Mon, 14 Nov 2011 18:39:14 -0500

   >> 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.

   > * 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.

   > 
===============================================================================
   >
   > * 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.

   > 
===============================================================================
   >
   > 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.

   > 
===============================================================================
   >
   > 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.

Thank you Bruno for running these tests they are immensly super duper
useful.  And to you Simon, for looking into things.  



reply via email to

[Prev in Thread] Current Thread [Next in Thread]