[bug-inetutils] Re: openbsd and bootstrap

[Mats Erik Andersson]

söndag den  2 januari 2010 klockan 10:48 skrev Alfred M. Szmidt detta:
> Mats, how exactly are you doing ./bootstrap && ./configure on OpenBSD?
> And with which version of OpenBSD, autoconf and automake?  Could you
> send the output of `./configure && cat config.log && make'?

To be honest I have not yet addressed the matter of getting the
bootstrapping to work with OpenBSD. Presently I perform the
bootstrap on my main development systen running Debian GNU/Linux
testing/squeeze. Then I alternate between an Rsync call and
a netcat-tar pipe at both ends. After that the configuration
script works like a charm also at a *BSD system.

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 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?

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

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


Best regards,
Mats