Re: [PATCH] Some Haiku Patches

[Ingo Weinhold]

On 2008-11-10 at 12:01:19 [+0100], Bruno Haible <address@hidden> wrote:
> Ingo Weinhold wrote:
> > >   - configure packages with
> > >     "./configure --host=i586-pc-beos --build=i586-pc-beos
> > >     --prefix=/boot/home/config"
> > 
> > As of revision 28582 Haiku comes with the latest versions of autoconf,
> > automake and friends. So after a "./bootstrap" or "automake --add-missing
> > --force-missing" (whatever is appropriate) configuring should be done 
> > with:
> >   ./configure --prefix=/boot/common
> 
> But GNU packages (i.e. tarballs distributed on ftp.gnu.org) are meant to be
> configured with a single "./configure" command, without other commands to
> be executed before.

Yeah, in a perfect world there would have been another automake release since 
1.10.1 supporting Haiku and all other software released would come with an 
up-to-date config.guess. Surprisingly some releases already ship with a 
config.guess supporting Haiku, but there's also software with an ancient 
version 
(e.g. flex 2.5.35 with a config.guess from 2005). I have no clue how 
problematic 
it is to specify an incorrect build platform (e.g. --build=i586-pc-beos on 
Haiku), but I suspect as soon as libtool is involved (which is somewhat broken 
for BeOS) I get suspicious.

> And the GNU packages ship with a config.guess that
> does not support Haiku; they bail out like this:
[...]
> There is definitely a problem with the 'uname' command on Haiku: "uname -m"
> should return something like "i586", not "BePC".

That's more or less a BeOS inheritance. And I don't see how that would be an 
actual problem. At least the POSIX specs define it somewhat vaguely to be the 
"name of the hardware type on which the system is running" (as opposed to 
"processor family" or something like this). Admittedly "i586" is certainly 
better than "BePC", but unless I'm much mistaken, the string is not 
standardized 
and shouldn't be treated as if it were. And isn't it exactly the job of 
config.guess to convert the non-standardized uname info to a canonical system 
name?

> Currently the output of
> "uname -a" gives no hint at all regarding the CPU type - I had to run "gcc 
> -v"
> to retrieve this information.
> 
> I have not yet investigated whether this is best fixed in the uname() 
> function
> or in the 'uname' program. The latter comes from coreutils, with relies on
> gnulib. Therefore I think it's reasonable to progress in this order:
>   - port gnulib,

That reminds me: Is there documentation on porting gnulib (the manual seems to 
focus on how to use it) and a test suite?

>   - port coreutils so that at least 'uname' compiles,
>   - find out whether the uname() function or the 'uname' program needs to
>     be fixed,

For sake of consistency uname() would be the place to change. Though ATM I'm 
not 
convinced that this is necessary. Doing so would probably break some software 
and scripts Haiku inherited from BeOS, while the only advantage I see is that 
"uname -m" would be a bit more precise, which at least autotools-using software 
shouldn't care about at all, since they use the canonicalized system name 
anyway.

>   - then only, once this is settled, send a mail to config-patches at 
>   gnu.org
>     requesting the inclusion of support for Haiku in config.guess.

That did already happen, which is actually one more reason against changing 
uname now.

CU, Ingo