[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Haiku port status
From: |
Ingo Weinhold |
Subject: |
Re: Haiku port status |
Date: |
Wed, 19 Nov 2008 02:07:24 +0100 |
User-agent: |
Beam 1.1.2 |
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
- [PATCH] Some Haiku Patches, Ingo Weinhold, 2008/11/05
- Re: [PATCH] Some Haiku Patches, Bruno Haible, 2008/11/09
- Re: [PATCH] Some Haiku Patches, Ingo Weinhold, 2008/11/09
- Re: [PATCH] Some Haiku Patches, Bruno Haible, 2008/11/10
- Re: [PATCH] Some Haiku Patches, Ingo Weinhold, 2008/11/10
- Re: [PATCH] Some Haiku Patches, Ralf Wildenhues, 2008/11/10
- Re: [PATCH] Some Haiku Patches, Bruno Haible, 2008/11/15
- Haiku port status, Bruno Haible, 2008/11/16
- Re: Haiku port status,
Ingo Weinhold <=
- Re: [PATCH] Some Haiku Patches, Karl Berry, 2008/11/10
- Re: config.guess origin, Bruno Haible, 2008/11/10