[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-inetutils] [Platform-testers] inetutils pre-release
From: |
Simon Josefsson |
Subject: |
Re: [bug-inetutils] [Platform-testers] inetutils pre-release |
Date: |
Tue, 15 Nov 2011 20:16:07 +0100 |
User-agent: |
Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) |
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
- [bug-inetutils] inetutils pre-release, Simon Josefsson, 2011/11/13
- Re: [bug-inetutils] [Platform-testers] inetutils pre-release, Bruno Haible, 2011/11/13
- Re: [bug-inetutils] [Platform-testers] inetutils pre-release, Simon Josefsson, 2011/11/14
- Re: [bug-inetutils] [Platform-testers] inetutils pre-release, Mats Erik Andersson, 2011/11/17
- Re: [bug-inetutils] [Platform-testers] inetutils pre-release, Mats Erik Andersson, 2011/11/17
- Re: [bug-inetutils] [Platform-testers] inetutils pre-release, Simon Josefsson, 2011/11/18
- [bug-inetutils] Readline code (Was: [Platform-testers] ...), Mats Erik Andersson, 2011/11/18
- Re: [bug-inetutils] Readline code, Simon Josefsson, 2011/11/19
- Re: [bug-inetutils] Readline code, Simon Josefsson, 2011/11/19
- Re: [bug-inetutils] Readline code, Mats Erik Andersson, 2011/11/19
- Re: [bug-inetutils] Readline code, Simon Josefsson, 2011/11/19
- Re: [bug-inetutils] Readline code, Mats Erik Andersson, 2011/11/19