[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug-inetutils] Re: openbsd and bootstrap
From: |
Mats Erik Andersson |
Subject: |
[bug-inetutils] Re: openbsd and bootstrap |
Date: |
Wed, 5 Jan 2011 14:43:15 +0100 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
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