Re: [bug-inetutils] Re: openbsd and bootstrap

[Alfred M. Szmidt]

   I have yet to discover any artifacts from the use of gcc-3.3.5,
   which is the default in OpenBSD. The noticeable problems are
   due to the outdated autotools suite in the standard installation.
   Some day I might be so annoyed as to do a manual compilation though.

I have recent autoconf and automake installed here, so not to do with
outdated tools.  GCC version shouldn't matter.

   > I get the following:
   > 
   > ...
   > ./configure[32854]: test: yes: unexpected operator/operand
   > ./configure[32873]: test: yes: unexpected operator/operand
   > ...
   > 
   > Since some of the tests in am/ are incorrect ("test $foo = yes", if
   > FOO is empty then this will fail on some versions of test.  This
   > should really be written as "test x$foo = xyes").

   No surprise here. Is it GNU, GNU Lib, or GNU Inetutils that carry
   the main responsibility here? In other words: Is it our project
   that has to scrutinise and correct this infrastructure?

A bit of both, a bit of both... We have some files in am/ that use the
non-portable syntax; but I noticed the same in gnulib.


   > Also, when doing a make, some files, for example lib/errno.h are not
   > properly generated:
   > 
   > errno.h:30:15: #include_next expects "FILENAME" or <FILENAME>

   Are you using BSD Make or GNU Make? In most circumstances the use
   of "gmake" works better, at least before a configure script has
   produces agnostic build files. The lack of a counter part to "gmake
   -C here/" in BSD Make is always bugging me when working on GNU
   Inetutils. I tend to build the full source with BSD Make, and then
   make limited recompilations with GNU Make to get around this
   nuissance.

I'm using GNU make; making things to work with BSD make is for another
rainy day...  As for the lack of -C in BSD make, that should be easy
to add.

   Could it be `include_next' that causes the above problem with BSD
   Make?  Did the incomplete configuration cause a strange inclusion
   path ordering, thus failing to find the intended header file? If
   you look at the call to the preprocessor/compiler, are the
   inclusion options making sense?  (I read the warning in section
   2.6, Wrapper headers, for Cpp.)

The problem exists because when doing the sed replacing in error.h.in,
the @FOO@ parts get replaced with empty values.  I.e. the problem is
reported by the compiler, not by make.

I'll try and fix all of this...