[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-inetutils] Re: openbsd and bootstrap
From: |
Alfred M. Szmidt |
Subject: |
Re: [bug-inetutils] Re: openbsd and bootstrap |
Date: |
Thu, 06 Jan 2011 13:43:19 -0500 |
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...