Greg Wooledge | 18 Sep 17:52 2009
Picon

build failure on HP-UX 11.11

GNU m4 1.4.13 fails to build on HP-UX 11.11:

make[4]: Entering directory `/usr/local/src/m4-1.4.13/lib'
 CC  gl_avltree_oset.o
In file included from sys/wait.h:91,
                 from sys/wait.h:28,
                 from stdlib.h:307,
                 from stdlib.h:34,
                 from gl_avltree_oset.c:25:
sys/resource.h:106: error: field `ru_utime' has incomplete type
sys/resource.h:107: error: field `ru_stime' has incomplete type

Line 106 of that file is "struct timeval ru_utime;" plus a comment.

I worked around this by editing the generated ./lib/sys/time.h file.
Before:

# if 0
#  include_next <sys/time.h>
# endif

After:

# if 1
#  include_next <sys/time.h>
# endif

After making that change, it was able to build, and passed the vast
majority of the "make check" test suite.

(Continue reading)

Eric Blake | 18 Sep 18:23 2009
Picon

Re: build failure on HP-UX 11.11


[adding gnulib]

According to Greg Wooledge on 9/18/2009 9:52 AM:
> GNU m4 1.4.13 fails to build on HP-UX 11.11:
> 
> make[4]: Entering directory `/usr/local/src/m4-1.4.13/lib'
>  CC  gl_avltree_oset.o
> In file included from sys/wait.h:91,
>                  from sys/wait.h:28,
>                  from stdlib.h:307,
>                  from stdlib.h:34,
>                  from gl_avltree_oset.c:25:
> sys/resource.h:106: error: field `ru_utime' has incomplete type
> sys/resource.h:107: error: field `ru_stime' has incomplete type
> 
> Line 106 of that file is "struct timeval ru_utime;" plus a comment.

Sounds like we're missing a header inclusion dependency.

> 
> I worked around this by editing the generated ./lib/sys/time.h file.
> Before:
> 
> # if 0
> #  include_next <sys/time.h>
> # endif
> 
> After:
> 
(Continue reading)

Greg Wooledge | 18 Sep 18:52 2009
Picon

Re: build failure on HP-UX 11.11

On Fri, Sep 18, 2009 at 10:23:09AM -0600, Eric Blake wrote:
> Hmm. That #if 0 line was generated from # if  <at> HAVE_SYS_TIME_H <at> .  Can you
> also attach config.log, and the make output, to see why HAVE_SYS_TIME_H
> might have been defined incorrectly?

Here's what looks like the relevant part of config.log:

configure:6233: checking for sys/time.h
configure:6233: gcc -std=gnu99 -c -g -O2  conftest.c >&5
In file included from inttypes.h:506,
                 from conftest.c:80:
wchar.h:87: error: syntax error before "va_list"
wchar.h:88: error: syntax error before "va_list"
wchar.h:89: error: syntax error before "va_list"
conftest.c:83:21: stdint.h: No such file or directory
configure:6233: $? = 1

Lines 87-89 of /usr/include/wchar.h are:

              extern int wprintf __((const wchar_t *, ...));
              extern int wscanf __((const wchar_t *, ...));
              extern size_t wcrtomb __((char *, wchar_t, mbstate_t *));

But it might not be using that one.  Lines 87-89 of
/usr/local/pa11_32/lib/gcc-lib/hppa1.1-hp-hpux11.11/3.4/include/wchar.h
are:

              extern int vfwprintf __((FILE *, const wchar_t *, va_list));
              extern int vwprintf __((const wchar_t *, va_list));
              extern int vswprintf __((wchar_t *, size_t, const wchar_t *, va_list));
(Continue reading)

Greg Wooledge | 18 Sep 21:08 2009
Picon

Re: build failure on HP-UX 11.11

The gcc bootstrap finally finished.  The failure I reported does not
occur with gcc 3.4.6 (+ GNU as) built from source on the same target
machine.  Whether this indicates a problem with the binary gcc build I
was using (specifically, its generated header files), or a problem in
m4's ./configure, I'm not sure.  But either way, you should know where
it stands.

Bruno Haible | 19 Sep 15:16 2009

Re: build failure on HP-UX 11.11

Greg Wooledge wrote:
> The gcc bootstrap finally finished.  The failure I reported does not
> occur with gcc 3.4.6 (+ GNU as) built from source on the same target
> machine.  Whether this indicates a problem with the binary gcc build I
> was using (specifically, its generated header files), or a problem in
> m4's ./configure, I'm not sure.  But either way, you should know where
> it stands.

Thanks for reporting the solution.

I agree with you that it was a problem with that particular gcc, because
  - the build works fine with the CC="cc -Ae -D_XOPEN_SOURCE=500" setting
    mentioned in the INSTALL file,
  - as you found out, gcc's private wchar.h uses va_list before including
    <stdarg.h>.

Bruno

Eric Blake | 19 Sep 15:19 2009
Picon

Re: build failure on HP-UX 11.11


According to Bruno Haible on 9/19/2009 7:16 AM:
> I agree with you that it was a problem with that particular gcc, because
>   - the build works fine with the CC="cc -Ae -D_XOPEN_SOURCE=500" setting
>     mentioned in the INSTALL file,
>   - as you found out, gcc's private wchar.h uses va_list before including
>     <stdarg.h>.

Can/should we work around this gcc bug, by ensuring that <stdarg.h> is
always included prior to <wchar.h> in all configure tests?

--
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9 <at> byu.net
Bruno Haible | 19 Sep 16:18 2009

Re: build failure on HP-UX 11.11

Eric Blake wrote:
> Can/should we work around this gcc bug, by ensuring that <stdarg.h> is
> always included prior to <wchar.h> in all configure tests?

I think it goes too far to attempt to work around bugs of every possible
gcc version on every possible platform.

  - The number of users of that particular version can be expected to be
    small. In contrast, the number of users of the vendor-provided compiler
    is higher.

  - The user can fix the problem by himself, in this case by adding one
    line to a gcc-private include file, or more generally by installing
    a newer version of gcc from source. This is not the case with
    vendor-provided compilers, often.

Bruno

Hiroyuki Yamamoto | 23 Sep 13:01 2009
Picon

make check failure on Debian GNU/Hurd

Hi,

GNU m4 1.4.13 fails to 'make check' on Debian GNU/Hurd.

Overview of the log is as follows:
--
...
Checking ./226.improved_m
Checking ./227.improved_c
Checking ./228.improved_c
Checking ./229.improved_c
Checking ./230.improved_f
Checking ./stackovf.test
Stack soft limit set to 300K
Failure - m4 aborted unexpectedly
Output from m4:
m4: internal error detected; please report this bug to <bug-m4 <at> gnu.org>: Segmentation fault

Failed checks were:
  ./stackovf.test
make[2]: Leaving directory `/home/foo/m4/m4-1.4.13/checks'
make[1]: Leaving directory `/home/foo/m4/m4-1.4.13'
--

Debian packages that are installed as follows:
texi2html  1.78-1

Regards,
--

-- 
Hiroyuki Yamamoto
(Continue reading)

Eric Blake | 23 Sep 14:14 2009
Picon

Re: make check failure on Debian GNU/Hurd


According to Hiroyuki Yamamoto on 9/23/2009 5:01 AM:
> Hi,
> 
> GNU m4 1.4.13 fails to 'make check' on Debian GNU/Hurd.
> 
> Checking ./stackovf.test
> Stack soft limit set to 300K
> Failure - m4 aborted unexpectedly
> Output from m4:
> m4: internal error detected; please report this bug to <bug-m4 <at> gnu.org>: Segmentation fault

Thanks for the report.  I believe there have been changes in gnulib that
might affect stack overflow detection, I should post a new snapshot to see
if that helps matters; and if not, the c-stack module needs to be fixed
for GNU/Hurd.  Meanwhile, could you help debug this further?  I don't have
access to GNU/Hurd to reproduce this.

Also, did your build pick up the libsigsegv library?  If so, which version?

--
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9 <at> byu.net
Hiroyuki Yamamoto | 23 Sep 16:26 2009
Picon

Re: make check failure on Debian GNU/Hurd


Hi,

Eric Blake wrote:
> According to Hiroyuki Yamamoto on 9/23/2009 5:01 AM: 
>> GNU m4 1.4.13 fails to 'make check' on Debian GNU/Hurd.
> 
>> Checking ./stackovf.test
>> Stack soft limit set to 300K
>> Failure - m4 aborted unexpectedly
>> Output from m4:
>> m4: internal error detected; please report this bug to <bug-m4 <at> gnu.org>: Segmentation fault
> 
> Thanks for the report.  I believe there have been changes in gnulib that
> might affect stack overflow detection, I should post a new snapshot to see
> if that helps matters; and if not, the c-stack module needs to be fixed
> for GNU/Hurd.  Meanwhile, could you help debug this further?  I don't have
> access to GNU/Hurd to reproduce this.

I do anything if possible, though there is not confidence.

> Also, did your build pick up the libsigsegv library?  If so, which version?

Hmm, I did build without installing libsigsegv library.
./configure did with following command:
$ env CFLAGS=-O2 ./configure --prefix=/usr/local/gnu --enable-changeword
$ make
$ make check

Then I tried making with libsigsegv library (Version 2.5-3 of Debian GNU/Hurd package).
(Continue reading)


Gmane