[Qemu-devel] [PATCH] [RFC] Haiku host support and general configure issues

[Qemu-devel] [PATCH] [RFC] Haiku host support and general configure issues

[Andreas Färber]

[-- Attachment #1: Type: text/plain, Size: 1643 bytes --]

Hello,

Haiku recently got an experimental GCC 4.3, so I was curious how far  
QEMU would get there now. This uncovered some generic issues with our  
configure tests that I think should be tackled before the release.

We have undocumented --extra-cflags= and --extra-ldflags= options that  
don't work as expected. They are ignored by all the configure tests,  
so it seems there is no direct equivalent to autoconf's CPPFLAGS to  
pass in additional header include paths. The OS_CFLAGS come closest,  
but they are ignored for some of the tests, too. Any preferences how  
to fix this?

On Haiku, zlib and ncurses headers are not in the default include  
path, so the current situation does not allow to configure QEMU at  
all. The attached patch adds a Haiku section to configure to hardcode  
the path in OS_CFLAGS and adds ${OS_CFLAGS} where necessary for Haiku.

It further sets OS_LDFLAGS to reference libnetwork.so, which contains  
the socket functions.

The optional curses support relies on -lcurses but it's called  
libncurses.a on Haiku, so add a check for -lncurses if -lcurses fails.  
It is then detected.

Unresolved issues include that AIO is detected, and as a consequence  
AIOLIBS is set to -lpthread but that is not available on Haiku.
The code still does not link qemu-img due to an unresolved symbol _IO  
in nbd code. Not sure if that's a missing check in QEMU or an issue in  
Haiku? There doesn't appear to be a switch to disable NBD altogether,  
so this seems like a blocker for now.

BTW, is it intentional that --disable-gfx-checks is not documented as  
part of --help, only when the checks do fail?

Andreas

[-- Attachment #2: qemu-haiku-01.diff --]
[-- Type: application/octet-stream, Size: 785 bytes --]

Index: configure
===================================================================
--- configure	(revision 6645)
+++ configure	(working copy)
@@ -297,6 +297,10 @@
 aix="yes"
 make="gmake"
 ;;
+Haiku)
+OS_CFLAGS="-I/boot/develop/headers/3rdparty"
+OS_LDFLAGS="-lnetwork"
+;;
 *)
 audio_drv_list="oss"
 audio_possible_drivers="oss alsa sdl esd pa"
@@ -933,8 +937,12 @@
 #include <curses.h>
 int main(void) { return curses_version(); }
 EOF
-  if $cc $ARCH_CFLAGS -o $TMPE $TMPC -lcurses > /dev/null 2> /dev/null ; then
+  if $cc $ARCH_CFLAGS -o $TMPE ${OS_CFLAGS} $TMPC -lcurses > /dev/null 2> /dev/null ; then
     curses=yes
+  else
+    if $cc $ARCH_CFLAGS -o $TMPE ${OS_CFLAGS} $TMPC -lncurses > /dev/null 2> /dev/null ; then
+      curses=yes
+    fi
   fi
 fi # test "$curses"
 

[-- Attachment #3: Type: text/plain, Size: 1033 bytes --]


---
Haiku support for configure

Add zlib include path to OS_CFLAGS and link against libnetwork.
Make the curses check respect OS_CFLAGS and check for -lncurses as well.

Signed-off-by: Andreas Faerber <andreas.faerber@web.de>


Index: configure
===================================================================
--- configure	(revision 6645)
+++ configure	(working copy)
@@ -297,6 +297,10 @@
  aix="yes"
  make="gmake"
  ;;
+Haiku)
+OS_CFLAGS="-I/boot/develop/headers/3rdparty"
+OS_LDFLAGS="-lnetwork"
+;;
  *)
  audio_drv_list="oss"
  audio_possible_drivers="oss alsa sdl esd pa"
@@ -933,8 +937,12 @@
  #include <curses.h>
  int main(void) { return curses_version(); }
  EOF
-  if $cc $ARCH_CFLAGS -o $TMPE $TMPC -lcurses > /dev/null 2> /dev/ 
null ; then
+  if $cc $ARCH_CFLAGS -o $TMPE ${OS_CFLAGS} $TMPC -lcurses > /dev/ 
null 2> /dev/null ; then
      curses=yes
+  else
+    if $cc $ARCH_CFLAGS -o $TMPE ${OS_CFLAGS} $TMPC -lncurses > /dev/ 
null 2> /dev/null ; then
+      curses=yes
+    fi
    fi
  fi # test "$curses"

[Qemu-devel] Re: [PATCH] [RFC] Haiku host support and general configure issues

[François Revol]

> We have undocumented --extra-cflags= and --extra-ldflags= options
> that
> don't work as expected. They are ignored by all the configure tests,
> so it seems there is no direct equivalent to autoconf's CPPFLAGS to
> pass in additional header include paths. The OS_CFLAGS come closest,
> but they are ignored for some of the tests, too. Any preferences how
> to fix this?

Ideally those shouldn't be needed anyway.

> The optional curses support relies on -lcurses but it's called
> libncurses.a on Haiku, so add a check for -lncurses if -lcurses
> fails.
> It is then detected.

ncurses is a different implementation but should be compatible AFAIK.

> Unresolved issues include that AIO is detected, and as a consequence

Then the test is buggy as we don't have AIO in Haiku that I know of :)

> AIOLIBS is set to -lpthread but that is not available on Haiku.

Well we should have a pthread lib available though...

> The code still does not link qemu-img due to an unresolved symbol _IO
> in nbd code. Not sure if that's a missing check in QEMU or an issue
> in
> Haiku? There doesn't appear to be a switch to disable NBD altogether,
> so this seems like a blocker for now.

Another big issue that I mentionned earlier here is the widely used
assumption that error codes are positive, which is not the case for
BeOS and Haiku.
Not fixing this will result in a dangerous binary.

François.

Re: [Qemu-devel] Re: [PATCH] [RFC] Haiku host support and general configure issues

[Andreas Färber]

Hello,

Am 28.02.2009 um 18:08 schrieb François Revol:

>> We have undocumented --extra-cflags= and --extra-ldflags= options
>> that
>> don't work as expected. They are ignored by all the configure tests,
>> so it seems there is no direct equivalent to autoconf's CPPFLAGS to
>> pass in additional header include paths. The OS_CFLAGS come closest,
>> but they are ignored for some of the tests, too. Any preferences how
>> to fix this?
>
> Ideally those shouldn't be needed anyway.

Not sure what exactly you're referring to, but both OS-specific as  
well as user-supplied settings may be necessary and should be working.  
Command line arguments are necessary to use self-compiled dependency  
libraries in their own prefix, for example.


>
>> Unresolved issues include that AIO is detected, and as a consequence
>
> Then the test is buggy as we don't have AIO in Haiku that I know of :)

Hm, the so-called AIO check is rather a pthreads check:

#include <pthread.h>
int main(void) { pthread_mutex_t lock;  return 0; }

If that compiles, a working -lpthread is assumed. It's buggy in itself  
because it first sets AIOLIBS="", then compiles with unchanged empty  
$AIOLIBS and then sets AIOLIBS="-lpthread".

>
>> AIOLIBS is set to -lpthread but that is not available on Haiku.
>
> Well we should have a pthread lib available though...

It's part of libroot.so, I thought, and thus referenced without extra  
linker arguments.


> Another big issue that I mentionned earlier here is the widely used
> assumption that error codes are positive, which is not the case for
> BeOS and Haiku.
> Not fixing this will result in a dangerous binary.

Thanks for the reminder. But that also reminds me, you wanted to  
supply a patch for that! :)

Andreas

Re: [HaikuPorts-devs] [Qemu-devel] Re: [PATCH] [RFC] Haiku host support and general configure issues

[François Revol]

> >> Unresolved issues include that AIO is detected, and as a
> > > consequence
> >
> > Then the test is buggy as we don't have AIO in Haiku that I know of
> > :)
>
> Hm, the so-called AIO check is rather a pthreads check:
>
> #include <pthread.h>
> int main(void) { pthread_mutex_t lock;  return 0; }
>
> If that compiles, a working -lpthread is assumed. It's buggy in
> itself
> because it first sets AIOLIBS="", then compiles with unchanged empty
> $AIOLIBS and then sets AIOLIBS="-lpthread".
>
> >
> >> AIOLIBS is set to -lpthread but that is not available on Haiku.
> >
> > Well we should have a pthread lib available though...
>
> It's part of libroot.so, I thought, and thus referenced without extra
> linker arguments.

Not sure we really want to keep it that way in Haiku then...

> > Another big issue that I mentionned earlier here is the widely used
> > assumption that error codes are positive, which is not the case for
> > BeOS and Haiku.
> > Not fixing this will result in a dangerous binary.
>
> Thanks for the reminder. But that also reminds me, you wanted to
> supply a patch for that! :)

You can always beat me to it.

François.

Re: [Qemu-devel] Re: [PATCH] [RFC] Haiku host support and general configure issues

[Jamie Lokier]

Andreas Färber wrote:
> Hm, the so-called AIO check is rather a pthreads check:
> 
> #include <pthread.h>
> int main(void) { pthread_mutex_t lock;  return 0; }
> 
> If that compiles, a working -lpthread is assumed. It's buggy in itself  
> because it first sets AIOLIBS="", then compiles with unchanged empty  
> $AIOLIBS and then sets AIOLIBS="-lpthread".
>
> >>AIOLIBS is set to -lpthread but that is not available on Haiku.
> >
> >Well we should have a pthread lib available though...

Note that "-lpthread" is not even a portable way to get pthreads -
even if it links successfully, it need not behave correctly.  (Think
of libc having different versions for threads and no-threads).

Maybe that's why Haiku doesn't have -lpthread.

-- Jamie

Re: [Qemu-devel] Re: [PATCH] [RFC] Haiku host support and general configure issues

[François Revol]

> Andreas Färber wrote:
> > Hm, the so-called AIO check is rather a pthreads check:
> >
> > #include <pthread.h>
> > int main(void) { pthread_mutex_t lock;  return 0; }
> >
> > If that compiles, a working -lpthread is assumed. It's buggy in
> > itself
> > because it first sets AIOLIBS="", then compiles with unchanged
> > empty
> > $AIOLIBS and then sets AIOLIBS="-lpthread".
> >
> > >>AIOLIBS is set to -lpthread but that is not available on Haiku.
> > >
> > >Well we should have a pthread lib available though...
>
> Note that "-lpthread" is not even a portable way to get pthreads -
> even if it links successfully, it need not behave correctly.  (Think
> of libc having different versions for threads and no-threads).

Note also some systems use -lpthreads and even others use a gcc flag -
pthread...

>
> Maybe that's why Haiku doesn't have -lpthread.

Most likely just to avoid spreading things outside of libroot.

Just like we don't have libm (it's in libroot, but noone ever checks
for it... you wonder what they use autoconf for then).

François.

Re: [Qemu-devel] Re: [PATCH] [RFC] Haiku host support and general configure issues

[Anthony Liguori]

Andreas Färber wrote:
> Hello,
>
> Am 28.02.2009 um 18:08 schrieb François Revol:
>
>>> We have undocumented --extra-cflags= and --extra-ldflags= options
>>> that
>>> don't work as expected. They are ignored by all the configure tests,
>>> so it seems there is no direct equivalent to autoconf's CPPFLAGS to
>>> pass in additional header include paths. The OS_CFLAGS come closest,
>>> but they are ignored for some of the tests, too. Any preferences how
>>> to fix this?
>>
>> Ideally those shouldn't be needed anyway.
>
> Not sure what exactly you're referring to, but both OS-specific as 
> well as user-supplied settings may be necessary and should be working. 
> Command line arguments are necessary to use self-compiled dependency 
> libraries in their own prefix, for example.

Because any use of them usually signifies that someone is doing 
something wrong.  For libraries that have non-standard install paths, we 
should be detecting it via pkg-config or the appropriate tool (like 
sdl-config).  For libraries that don't support these (like zlib), the 
expectation is that they will be available in prefix.

>>> Unresolved issues include that AIO is detected, and as a consequence
>>
>> Then the test is buggy as we don't have AIO in Haiku that I know of :)
>
> Hm, the so-called AIO check is rather a pthreads check:
>
> #include <pthread.h>
> int main(void) { pthread_mutex_t lock;  return 0; }
>
> If that compiles, a working -lpthread is assumed. It's buggy in itself 
> because it first sets AIOLIBS="", then compiles with unchanged empty 
> $AIOLIBS and then sets AIOLIBS="-lpthread".

So we need to also make a pthread call.  Like int main(void) { 
pthread_mutex_init; return 0; }

>> Well we should have a pthread lib available though...
>
> It's part of libroot.so, I thought, and thus referenced without extra 
> linker arguments.

So we should try to compile against -lpthread and then try to compile 
against -lroot.  Or better yet, does -pthread do the right thing on 
haiku?  We could just switch to that.

>
>> Another big issue that I mentionned earlier here is the widely used
>> assumption that error codes are positive, which is not the case for
>> BeOS and Haiku.
>> Not fixing this will result in a dangerous binary.
>
> Thanks for the reminder. But that also reminds me, you wanted to 
> supply a patch for that! :)

Such a patch may be something ya'll have to maintain on your own.  This 
has been discussed a lot in the past and I'm concerned that it's going 
to be too invasive.

Regards,

Anthony Liguori

>
> Andreas
>
>
>

Re: [HaikuPorts-devs] [Qemu-devel] Re: [PATCH] [RFC] Haiku host support and general configure issues

[François Revol]

> >> Well we should have a pthread lib available though...
> >
> > It's part of libroot.so, I thought, and thus referenced without
> > extra
> > linker arguments.
>
> So we should try to compile against -lpthread and then try to compile
> against -lroot.  Or better yet, does -pthread do the right thing on
> haiku?  We could just switch to that.

-lroot is implied, not needed, so pthread is available without any
flag.

> >> Another big issue that I mentionned earlier here is the widely
> > > used
> >> assumption that error codes are positive, which is not the case
> > > for
> >> BeOS and Haiku.
> >> Not fixing this will result in a dangerous binary.
> >
> > Thanks for the reminder. But that also reminds me, you wanted to
> > supply a patch for that! :)
>
> Such a patch may be something ya'll have to maintain on your own.
> This
> has been discussed a lot in the past and I'm concerned that it's
> going
> to be too invasive.

Too busy to start on it again.
There is nothing wrong with it if done cleanly. It might even help
catch up mistakes.

François.

Re: [Qemu-devel] Re: [PATCH] [RFC] Haiku host support and general configure issues

[Avi Kivity]

Anthony Liguori wrote:
>>
>>> Another big issue that I mentionned earlier here is the widely used
>>> assumption that error codes are positive, which is not the case for
>>> BeOS and Haiku.
>>> Not fixing this will result in a dangerous binary.
>>
>> Thanks for the reminder. But that also reminds me, you wanted to 
>> supply a patch for that! :)
>
> Such a patch may be something ya'll have to maintain on your own.  
> This has been discussed a lot in the past and I'm concerned that it's 
> going to be too invasive.

We could define a qemu_errno() which returns errno converted to positive 
numbers.  While it will touch a lot of places, I don't think it can be 
considered invasive.

-- 
error compiling committee.c: too many arguments to function

Re: [HaikuPorts-devs] [Qemu-devel] Re: [PATCH] [RFC] Haiku host support and general configure issues

[François Revol]

> Anthony Liguori wrote:
> >>
> >>> Another big issue that I mentionned earlier here is the widely
> > > > used
> >>> assumption that error codes are positive, which is not the case
> > > > for
> >>> BeOS and Haiku.
> >>> Not fixing this will result in a dangerous binary.
> >>
> >> Thanks for the reminder. But that also reminds me, you wanted to
> >> supply a patch for that! :)
> >
> > Such a patch may be something ya'll have to maintain on your own.
> > This has been discussed a lot in the past and I'm concerned that
> > it's
> > going to be too invasive.
>
> We could define a qemu_errno() which returns errno converted to
> positive
> numbers.  While it will touch a lot of places, I don't think it can
> be
> considered invasive.

I'm used to using the opposite, RETERR() returning always negative
codes from either errno or E*, and it works quite well.

I don't see the point in making stuff positive to return them negated.

Besides, one of the error codes in BeOS & Haiku will certainly overflow
on 32bit (B_NO_MEMORY = B_GENERAL_ERROR_BASE = LONG_MIN).

François.

Re: [HaikuPorts-devs] [Qemu-devel] Re: [PATCH] [RFC] Haiku host support and general configure issues

[Avi Kivity]

François Revol wrote:
>> We could define a qemu_errno() which returns errno converted to 
>> positive 
>> numbers.  While it will touch a lot of places, I don't think it can 
>> be 
>> considered invasive.
>>     
>
> I'm used to using the opposite, RETERR() returning always negative 
> codes from either errno or E*, and it works quite well.
>
> I don't see the point in making stuff positive to return them negated.
>   

Changing errno to qemu_errno() is not an invasive change (at least, not 
much).  Adding a RETERR() is, with significant chance for regressions.

> Besides, one of the error codes in BeOS & Haiku will certainly overflow 
> on 32bit (B_NO_MEMORY = B_GENERAL_ERROR_BASE = LONG_MIN).
>   

qemu_errno() on Haiku could change it to something else.

-- 
error compiling committee.c: too many arguments to function

Re: [HaikuPorts-devs] [Qemu-devel] Re: [PATCH] [RFC] Haiku host support and general configure issues

[François Revol]

> François Revol wrote:
> >> We could define a qemu_errno() which returns errno converted to
> >> positive
> >> numbers.  While it will touch a lot of places, I don't think it
> > > can
> >> be
> >> considered invasive.
> >>
> >
> > I'm used to using the opposite, RETERR() returning always negative
> > codes from either errno or E*, and it works quite well.
> >
> > I don't see the point in making stuff positive to return them
> > negated.
> >
>
> Changing errno to qemu_errno() is not an invasive change (at least,
> not
> much).  Adding a RETERR() is, with significant chance for
> regressions.

Except it's not enough.
It's _not_ only errno that is < 0, but the E* codes too.
so all return -EFOO are indeed broken.

Another option is tu #define other codes from E* like QEINVAL, ...
OSSv4 does this.

Anyway, I'm too busy to look into it yet, will see later.

François.