Daniel Veillard:
applied
hmm... i just downloaded cvs again to make new diff and my changes appeared in diff again - like they were not applied :(
the configure.ac file contains AC_DEFINE macros which are extracted by the autoheader tool and put into the config.h.in template.
i couldn't find configure.ac. Daniel Veillard:
check configure.in look for "case ${host} in" and try to find the
appropriate BeOS options.
Stefan Seefeld:
...and add AC_DEFINE(HAVE_BEOS_THREADS, ...) there. That should do the job.
THX :) i'm sending diff with changes to configure.in (and changes i made before but they were not in cvs). I tried to make it clean and readable, also with place for other platforms. Can someone generate configure script from it and test if it works? :) Bjorn Reese:
1. Using a data type without confirming that it is the correct type is a classic portability pitfall. According to your line of reasoning it should be ok to use a double, but does the setsockopt() implementation handle this correctly (I would guess not, as it has no indication about the encoding of the data passed, only its size.)
ok, i've checked that in BeBook (BeOS API docs) again, and it stays there: "For the SO_NONBLOCK option (and other boolean options), you fill the buffer with zeroes if you want to turn the option off (the socket will block), and non-zeros if you want to turn it on (the socket won't block). In the case of a boolean option, a single byte of zero/non-zero will do." (online version: http://bang.dhs.org/be/bebook/The%20Network%20Kit/Sockets.html ) Also reading opengroup docs one can think it doesn't matter what type You point to, as long as bytes are properly set. AFAIK it could even be string of 569 chars, and size 569 :)
2. The bool type is not a standard C data type.
but it's standard on BeOS, and since it's BeOS only part of code... Anyway i changed it to int - it works here anyway, and there will be no fight for few bytes :) Regards Shard
Attachment:
libxml2-2.6.1-BeOS.diff
Description: Text document