Bug 183253

Comment 1 Edwin Groothuis 2013-10-24 03:10:15 UTC

Responsible Changed
From-To: freebsd-ports-bugs->bapt

Over to maintainer (via the GNATS Auto Assign Tool)

This looks buggy to me, that means in your case the configure script failed
at determining this, I'm succesfully building zsh on 10 and 11.

Can you send me the config.log of zsh when it fails?

Comment 3 Yasuhiro Kimura 2013-10-24 09:40:57 UTC

From: Baptiste Daroussin <baptiste.daroussin@gmail.com>
Subject: Re: ports/183253: [PATCH] shells/zsh: fail to build on 10.0-BETA1
Date: Thu, 24 Oct 2013 08:51:05 +0200

> This looks buggy to me, that means in your case the configure script failed
> at determining this, I'm succesfully building zsh on 10 and 11.
> Can you send me the config.log of zsh when it fails?

I put it follwing URL:

http://www.utahime.org/zsh-5.0.2_1.config.log

Regards.

Comment 4 Baptiste Daroussin 2014-01-25 23:46:51 UTC

Is it still happening with recent versions?

Comment 5 Yasuhiro Kimura 2014-01-27 10:42:55 UTC

Hello.

First of all, thank you remind me of this PR.

> Is it still happening with recent versions?

Yes. But I found there is one requirement that I was not aware of
before. That is, build fails only when system is NIS client. More
precisely it happens when "/usr/bin/ypcat passwd.byname" returns
status value of 0.

At line 10710 of zsh-5.0.5/configure there is a test as following:

----------------------------------------------------------------------
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for NIS" >&5
$as_echo_n "checking for NIS... " >&6; }
if ${zsh_cv_sys_nis+:} false; then :
  $as_echo_n "(cached) " >&6
else
  test -f /usr/bin/ypcat && /usr/bin/ypcat passwd.byname > /dev/null 2>&1 && \
zsh_cv_sys_nis=yes || zsh_cv_sys_nis=no
fi
----------------------------------------------------------------------

If system is NIS client, "/usr/bin/ypcat passwd.byname" normally
succeeds and ends with return value 0. If return valued is 0 shell
variable "zsh_cv_sys_nis" is set to "yes" and this results that
HAVE_NIS macro is defined in configure.h as following:

----------------------------------------------------------------------
/* Define to 1 if you have NIS. */
#define HAVE_NIS 1
----------------------------------------------------------------------

And this macro affects inclusion of header files in
zsh-5.0.5/Src/hashnameddir.c. From line 30 it continues as following:

----------------------------------------------------------------------
#include "../config.h"

/*
 * On Solaris 8 there's a clash between "bool" in curses and RPC.
 * We don't need curses here, so ensure it doesn't get included.
 */
#define ZSH_NO_TERM_HANDLING

#include "zsh.mdh"
#include "hashnameddir.pro"

/****************************************/
/* Named Directory Hash Table Functions */
/****************************************/

#ifdef HAVE_NIS_PLUS
# include <rpcsvc/nis.h>
#else
# ifdef HAVE_NIS
#  include      <rpc/types.h>
#  include      <rpc/rpc.h>
#  include      <rpcsvc/ypclnt.h>
#  include      <rpcsvc/yp_prot.h>
# endif
#endif
----------------------------------------------------------------------

As written above HAVE_NIS macro is defined in configure.h. So
/usr/include/rpcsvc/yp_prot.h is to be included. And at line 70 of
yp_prot.h there is definition of 'bool' as following:

----------------------------------------------------------------------
#ifndef BOOL_DEFINED
typedef u_int bool;
#define BOOL_DEFINED
#endif
----------------------------------------------------------------------

Now let's go back Src/hashnameddir.c. At line 38 it includes
Src/zsh.mdh. At line 17 of Src/zsh.mdh it includes Src/zsh_system.h.
At line 510 of Src/zsh_system.h it includes /usr/include/sys/capability.h.
At line 50 of /usr/include/sys/capability.h it includes
/usr/includes/stdbool.h. And at line 37 of /usr/includes/stdbool.h
there is again definition of 'bool' as following:

----------------------------------------------------------------------
#define bool    _Bool
----------------------------------------------------------------------

And according to result of executing following sample program, 'u_int'
is type of 4 bytes while '_Bool' is one of 1 byte.

----------------------------------------------------------------------
yasu@eastasia[25907]% uname -a
FreeBSD eastasia.home.utahime.org 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260673: Thu Jan 23 22:36:39 JST 2014     root@eastasia.home.utahime.org:/usr0/freebsd/src/obj/usr0/freebsd/src/releng_10_0/src/sys/EASTASIA  amd64
yasu@eastasia[25908]% cat booltest.c
#include <stdio.h>
#include <sys/types.h>

int
main(int argc, char** argv)
{
    printf("sizeof(u_int)=%lu, sizeof(_Bool)=%lu\n",
           sizeof(u_int), sizeof(_Bool));
    return 0;
}
yasu@eastasia[25909]% cc -o booltest booltest.c
yasu@eastasia[25910]% ./booltest
sizeof(u_int)=4, sizeof(_Bool)=1
yasu@eastasia[25911]%
----------------------------------------------------------------------

Now there are conflicting definitions of 'bool' type between
/usr/include/rpcsvc/yp_prot.h and /usr/includes/stdbool.h. And it
results in complation failure of Src/hashnameddir.c as following:

----------------------------------------------------------------------
cc -c -I. -I../Src -I../Src -I../Src/Zle -I. -I/usr/local/include -DHAVE_CONFIG_H -O2 -pipe -fno-strict-aliasing  -o hashnameddir.o hashnameddir.c
In file included from hashnameddir.c:52:
/usr/include/rpcsvc/yp_prot.h:71:15: error: cannot combine with previous
      'type-name' declaration specifier
typedef u_int bool;
              ^
/usr/include/stdbool.h:37:14: note: expanded from macro 'bool'
#define bool    _Bool
                ^
1 error generated.
----------------------------------------------------------------------

As described above source of failure exists in FreeBSD rather than
zsh. My patch is workarounding compilation failure by disabling type
definition of bool in /usr/include/rpcsvc/yp_prot.h but it is
undoubtedly bad way because it ignores size mismatch of two bool
definitions.

That is all I have investigated. I hope this will help to fix the
probrem.

Best Regards.

---
Yasuhiro KIMURA

Comment 6 Baptiste Daroussin 2014-06-22 22:47:50 UTC

Sorry I have been very long to reply to this, I'll see how I can fix directly the base system, in the mean time I'll look at applying your patch