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

[Anthony Liguori <anthony@codemonkey.ws>]

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
>
>
>