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: Simon Josefsson
Subject: Re: [bug-inetutils] [Platform-testers] inetutils pre-release
Date: Mon, 14 Nov 2011 11:21:31 +0100
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.91 (gnu/linux)

Bruno Haible <address@hidden> writes:

> Simon Josefsson wrote:
>> 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.

Thank you for very extensive testing!

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

> In other words, you need to add $(LIBREADLINE) to the value of LDADD
> in telnet/Makefile.am.
>
> Likewise in telnetd/Makefile.am.

Thanks for analyzing, I agree and pushed this tiny change in your name.

> Quite odd situation, but IMO the readline macro should not set 
> HAVE_LIBREADLINE
> if the include files are missing, or the code in ftp/cmds.c should be testing
>   HAVE_LIBREADLINE && HAVE_READLINE_READLINE_H
> instead of just
>   HAVE_LIBREADLINE

Yes.  However, wouldn't an even better solution be to use
AC_LIB_LINKFLAGS here instead of the current check for readline?  That
should be more reliable.

> ===============================================================================
>
> * MacOS X 10.5, FreeBSD 6.4
>
>   CCLD   ftp
> Undefined symbols:
>   "_fdopendir", referenced from:
>       _rpl_getcwd in libgnu.a(getcwd.o)
>   "_fstatat", referenced from:
>       _rpl_getcwd in libgnu.a(getcwd.o)
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make[2]: *** [ftp] Error 1
>
> Similarly on IRIX 6.5:
>
>   CC     getcwd.o
> cc-1196 cc: WARNING File = getcwd.c, Line = 246
>   The indicated function is declared implicitly.
>
>         dirstream = fdopendir (fd);
>                     ^
>
> cc-1515 cc: ERROR File = getcwd.c, Line = 246
>   A value of type "int" cannot be assigned to an entity of type "DIR *".
>
>         dirstream = fdopendir (fd);
>                   ^
>
> 1 error detected in the compilation of "getcwd.c".
> *** Error code 2 (bu21)

Why isn't gnulib pulling in fdopendir and fstatat?  Alternatively, how
come HAVE_OPENAT_SUPPORT is set on these platforms?

> * OpenBSD 4.9
>
>   CC     logger.o
> logger.c:47:22: error: logprio.h: No such file or directory
> *** Error code 1
>
> No platform I know of has a <logprio.h> file, and inetutils does not contain
> this file either.

Should be fixed now.

> * NetBSD 5.1
>
>   CC     commands.o
> commands.c: In function 'makeargv':
> commands.c:149: warning: array subscript has type 'char'
> commands.c:182: warning: array subscript has type 'char'
> commands.c: In function 'send_tncmd':
> commands.c:435: error: conflicting types for 'telopts'
> /usr/include/arpa/telnet.h:150: error: previous declaration of 'telopts' was 
> here
> commands.c: In function 'help':
> commands.c:2968: warning: field width should have type 'int', but argument 2 
> has type 'long unsigned int'
> commands.c:2968: warning: field width should have type 'int', but argument 2 
> has type 'long unsigned int'
> commands.c: In function 'cmdrc':
> commands.c:3025: warning: array subscript has type 'char'
> commands.c:3030: warning: array subscript has type 'char'
> *** Error code 1
>
> The declaration in /usr/include/arpa/telnet.h:150 is:
> extern const char *telopts[NTELOPTS+1];
> where NTELOPTS is 48.

Interesting.  On Debian it is:

char *telopts[NTELOPTS+1] = {

I can't find where 'telopts' is specified (I looked at POSIX and the
glibc manual).  Possibly inetutils just has to look at installed headers
and see whether the const is needed or not.  Sigh.

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

> ===============================================================================
>
> * HP-UX 11.00
>
>   CC     utmp_logout.o
> cc: "utmp_logout.c", line 76: error 1588: "e_termination" undefined.
> cc: "utmp_logout.c", line 76: error 1531: Invalid member of struct or union.
> cc: "utmp_logout.c", line 77: error 1588: "e_exit" undefined.
> cc: "utmp_logout.c", line 77: error 1531: Invalid member of struct or union.
> gmake[2]: *** [utmp_logout.o] Error 1
>
> The 'struct utmpx' on HP-UX has a field ut_exit with components called
> __e_termination and __e_exit, not e_termination and e_exit.

I'll leave this for later.

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

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

/Simon



reply via email to

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