Henning Meier-Geinitz wrote: > Hi, [...] >>1. if we just use the vanilla 'configure' without specifing any >>arguments then we get an error when compiling backend/coolscan.c, at >>line 2593. The error is: sa_handler field doesn't exists. > > Strange. sa_handler is also used by other backends. Maybe we need > another definition for SIGACTION in sanei/sanei_backend.h?
I checked even with the latest gcc 3.3.3. I cannot tell what happened, but the 1.0.14 is compiled correctly while the CVS snapshot isn't. >>2. if you use a different compiler, i.e., 'gcc-2' instead of 'gcc', the >>compilation process stops on backend/gt68xx.c, line 242, since SHM_R is >>not definded. How may we tell 'configure' to do not compile a specific >>backend? Should we specify all other backends we need using the BACKENDS >>variable? >> >>gt68xx_shm_channel.c: In function `shm_channel_new': >>gt68xx_shm_channel.c:242: `SHM_R' undeclared (first use in this function) >>gt68xx_shm_channel.c:242: (Each undeclared identifier is reported only once >>gt68xx_shm_channel.c:242: for each function it appears in.) >>gt68xx_shm_channel.c:242: `SHM_W' undeclared (first use in this function > > > I'll add a workaround for that one to CVS. If you like to use that > backend, you can also edit gt68xx.c and #undef USE_FORK. For this I found a different fix: Instead of including ipc.h ans shm.h I did included cygipc/ipc.h and cygipc/shm.h. I did this change in all backends that require SHM_R. Moreover I found another problem when using the libusb-win32: please have a look at the the bug tracking in Alioth (when it will be up again). Finally there is a problem when trying to compile the japi directory: a file Sane.h is missing and the makefile looks for libsane.so in ../backend/libs instead of ../backend/.libs . (I did not reported the bug since Alioth is unreachable). Bye, Giuseppe
