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