Re: Haiku port status

[Ingo Weinhold]

On 2008-11-15 at 12:42:20 [+0100], Bruno Haible <address@hidden> wrote:

Sorry for the late reply. I'm just back from a rather busy business trip and 
trying to catch up with my emails.

> Ingo Weinhold [are you 'bonefish'?] wrote:

I am indeed.

On 2008-11-16 at 18:39:47 [+0100], Bruno Haible <address@hidden> wrote:
> 
> I wrote:
> > Porting gnulib to a particular platform means:
> >   - doing a "gnulib-tool --create-testdir --with-tests", transferring 
that
> >     to the target system, and running it there, and fixing all the 
> >     problems,
> > ...
> 
> The status of this step is that, except for a couple of patches to gnulib
> that I have committed, proposed, or that are in the pipe, the following
> issues remain. They should better be fixed in Haiku.

Thanks a lot! Your work is very much appreciated.

>   - <http://dev.haiku-os.org/ticket/3136> This makes many tests which use
>     'long double' fail. This is critical, because gnulib now assumes 
working
>     'long double' on all platforms.

For sake BeOS binary compatibility Haiku does by default still use gcc 
2.95.3. I don't know whether "long double" support was generally broken in 
this gcc version or if only the BeOS and Haiku ports are affected. In the 
latter case it's likely possible to fix without too much effort. If it is 
generally broken, we (the Haiku devs) will probably weigh the overhead of 
doing that against just hacking the GNU software that uses "long double" 
until we migrate to gcc 4.

>   - <http://dev.haiku-os.org/ticket/3143> st_ctime appears to be 
>   unimplemented.

AFAIK our primary file system BFS (known as BeFS in the GNU/Linux world) 
doesn't store st_ctime on disk and therefore treats it synonymous to 
st_mtime. That can't be fixed until we break on-disk compatibilty. How much 
of a problem is this with respect to gnulib?

>   - All thread related tests (test-lock, test-tls, test-cond) hang. For
>     test-lock, it hangs in a state where the main thread is waiting for the
>     other threads, and the other threads are each blocking in 
sched_yield().
>     This shouldn't happen: threads which do sched_yield() should be woken 
up
>     every now and then.

This does indeed sound like a bug. Will have to look into this to understand 
what goes wrong.

>   - <http://dev.haiku-os.org/ticket/3148> select() may hang on a tty.

Should be fixed in r28687 (http://dev.haiku-os.org/changeset/28687).

>   - gnulib's poll() replacement hangs in a recv() call, apparently because
>     recv() does not support the MSG_PEEK flag.

At least the TCP code seems to deal with the flag (could be buggy, though). 
Other protocols don't implement it yet. That's something that needs to be 
done.

> What is the way to
>       1. distinguish a connected from an unconnected socket?

I'm not a networking expert, but I suppose getpeername() should succeed when 
connected (at least for protocols that require binding for connections) and 
fail if unconnected.

>       2. tell whether a socket is hung up?

Not sure what you mean by "hung up". A regular shutdown() on the local 
socket or any kind of shutdown() or disconnect that happened remotely? In 
either case, I'm not sure, if it is possible to discriminate those 
conditions.

>   - <http://dev.haiku-os.org/ticket/3145> fseek after ungetc bug.

Probably a bug introduced when hacking glibc to be binary compatible to 
BeOS' version.

>   - <http://dev.haiku-os.org/ticket/3141> This causes a failure of 
>   test-flock.

OK. Doesn't sound too hard to fix.

> Other issues:
> 
>   - Waiting for a new automake release with updated config.guess.
> 
>   - Mention the recommended configuration options for Haiku in the
>     INSTALL file. Can you tell what is the difference (in intent and use)
>     of /boot/home/config and /boot/common? I note the default PATH has
>     /boot/home/config/bin before /boot/common/bin.

This has to be seen in the context of BeOS' and (ATM) Haiku's restricted 
multi-user support. While kernel and C library generally support Unixish 
multiple users (though protecting them from each other doesn't happen in a 
lot of situations) pretty much all components associated with the graphical 
interface can deal only with one user, the root user. The user's home 
directory is /boot/home, software only for herself is installed in prefix 
/boot/home/config. Software for all users is installed in prefix 
/boot/common. ATM, having only a single user, it doesn't really make a 
difference in which of these two locations something is installed, but as 
soon as Haiku has grown full multi-user support only /boot/common will work 
as desired, so we've already discouraged /boot/home/config. I.e. all 
software packages should be configured with "--prefix=/boot/common".

> You can close <http://ports.haiku-files.org/ticket/70>. It has been 
> implemented here:
> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=a2c5f8d99ec52594aae96afeb29e0aeb7a841872

Thanks a lot!

Will forward this mail to the Haiku developer list. Maybe someone there can 
say more about the issues I'm not that familiar with.

CU, Ingo