Date: Sun, 14 Aug 2005 00:05:15 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 599 ************************************************** Saturday 13 August 2005 Number 599 ************************************************** Subjects for today 1 Problems compiling Brother backend for Sane : Paul Smedley 2 Re: Problems compiling Brother backend for Sane : Stefan.Neis at t-online.de **= Email 1 ==========================** Date: Sat, 13 Aug 2005 20:30:47 +0930 From: Paul Smedley Subject: Problems compiling Brother backend for Sane Hi All, I've started looking at some of the external backends for Sane now that the USB support seems pretty solid. First one I've looked at is the brscan2 backend for Brother Multifunction devices from: http://solutions.brother.com/linux/sol/printer/linux/sane_drivers.html Unfortunately this dies almost immediately with: U:/USR/include/os2emx.h:208: error: conflicting types for `BOOL' brother_dtype.h:10: error: previous declaration of `BOOL' U:/USR/include/os2emx.h:5341: error: parse error before ';' token In file included from brother_devinfo.c:16, from brother2.c:97: u:/extras/include/pthread.h:18: error: conflicting types for `HANDLE' brother_dtype.h:25: error: previous declaration of `HANDLE' os2emx.h defines BOOL as: typedef unsigned long BOOL; brother_dtype.h defines BOOL as: typedef int BOOL; obviously I tried commenting out the definition in brother_dtype.h and things seemed to get a little further, however then I got a bunch of other errors all around BOOL statements - presumably due to the change in definition from the expected int to unsigned long. Then there's the pthread declaration of HANDLE: typedef ULONG HANDLE; compared with the brother_devinfo definition of typedef void *HANDLE; Any ideas on how to handle this? Cheers, Paul. **= Email 2 ==========================** Date: Sat, 13 Aug 2005 13:24:16 +0100 From: Stefan.Neis at t-online.de Subject: Re: Problems compiling Brother backend for Sane Hi, > obviously I tried commenting out the definition in brother_dtype.h and > things seemed to get a little further, however then I got a bunch of > other errors all around BOOL statements - presumably due to the change > in definition from the expected int to unsigned long. Yes, the code probably relies on it's own definitions... Maybe you could try adding #define _OS2EMX_H to brother_dtype.h, so os2emx.h essentially won't be included, thus getting around those mismatching definitions the other way. I don't think the current code can possibly relying on much of the defitions in os2emx.h, so this might work ... Regards, Stefan