# Re: Compiling on OS/2

From: Henning Meier-Geinitz (henning@meier-geinitz.de)
Date: Thu May 31 2001 - 10:06:16 PDT

- Next message: Henning Meier-Geinitz: "assert.h problems with shared libraries"
  - Previous message: Henning Meier-Geinitz: "Re: [PATCH] Re: SANE CVS snapshot (2001-05-30) available"
  - In reply to: Franz Bakan: "Re: Compiling on OS/2"
  - Next in thread: Franz Bakan: "Re: Compiling on OS/2"
  - Reply: Franz Bakan: "Re: Compiling on OS/2"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  Hi,

  On Thu, May 31, 2001 at 01:54:57AM +0200, Franz Bakan wrote:
  > >> sanei_scsi.c:line: initializer element for `param[0].u' is not
  > >> computable at load time
  > >
  > >At which line is this error? I would think it's on 2432-2439,
  >
  > no its at line 3369ff

  Ah, that's the special case for OS/2. Looks like a bug.

  > btw. in version 1.03 (line 2133) these variables were static.
  > (So I got the idea to make them static to get it compiled and
  > it worked)

  I think the correct fix is to don't use an initializer but to set the
  values manually as in the non-os/2 version. This was changed by Abel
  Deuring on 2001-01-07 but only for the non-os/2 version. I will change
  that, please try when the change has been commited to cvs.

  > >So I just don't understand this. By the way: Does it work if you use
  > >"configure --disable-warnigs"? The warnings will be disabled for
  > >release.
  > I did not try, I will try when I have time.
  > It's not a warning, it's an error.
  > does --disable-warnings change what is treated as error?

  It shouldn't but e.g. -ansi may have side effects. I think there was a
  similar problem with sanei_scsi.c on OS/2 some time ago which went
  away when disabling warnings but I may be wrong.

  > >
  > >> 2. sane/sane-backends/backend/qcam.c
  > >>
  > >> I have to change
  > >>
  > >> struct flock sfl;
  > >>
  > >> to
  > >>
  > >> struct
  > >> { off_t l_start;
  > >> off_t l_len;
  > >> pid_t l_pid;
  > >> short l_type;
  > >> short l_whence;
  > >> } sfl;
  > >
  > >Could you check if this struct is defined in any of your system
  > >headers? If it isn't, we can probably do some kind of configure magic
  > >to define it if it isn't.
  >
  > No it's not defined in the system-headers /emx/include/...

  Ok. I will think about how to fix it. Would it help if it's defined in
  config.h.in?

  > >
  > >> 3. in sane/sane-backends/lib/*.c
  > >>
  > >> I have to change
  > >> #include "config.h"
  > >> to
  > >> #include <config.h>
  > >
  > >In principle, this should work with "config.h" because the include
  > >dirs are -I$(top_builddir)/include/sane -I$(top_srcdir)/include and
  > >config.h is in include/sane. Could you have a look into the Makefile
  > >and check, if these entries are the same (INCLUDES)?
  > >
  > >But usually we use "../include/sane/config.h" or at least
  > >"sane/config.h". I don't know why it doesn't work for you and why it
  > >does with <config.h>.
  >
  > I think it should be "../include/sane/config.h"
  > I think <config.h> is searched in the include-path
  > and "config.h" is treated as absolute path

  But as the compiler is called with -I../include and -I../include/sane
  config.h is in the include-path in both cases. But it doesn't matter,
  I will change it.

  > After this I had to change the makefiles.
  > I had to change
  > sh LIBTOOL = ../libtool
  > to
  > LIBTOOL = ../libtool
  > in some makefiles

  Could you explain where this is located exactly? I don't understand
  what "sh LIBTOOL = ../libtool" should do and how the line was
  generated.

  > Then it compiled but did not link
  > I had to remove the umax_pp backend because of undefined references
  > '_outb' and such things...

  Yes, there seem to be some problems with parport access that should be
  fixed for 1.0.6.

  > and I had to add manually some libs to the link-command which I executed in
  > sane-backends/frontend/
  >
  > I used
  >
  > GCC -Zexe -Zcrtdll -Zsysv-signals -o scanimage scanimage.o
  > stiff.o -lbsd -lsocket -lm /emx/lib/iberty.a ../backend/.libs/libsane.a
  > ../lib/liblib.a /XFree86/lib/shm.a /emx/lib/syslog.a /emx/lib/socket.a
  >
  > to get the static linked executable.

  Ok, looks a bit complicated :-) Could you write down this procedure
  and put it on a webpage for other OS/2 users? So we could add a link
  on the SANE web page to it. If you can't, I could put it somewhere on
  my website.

  > It works with my EPSON GT-9500 scanner.
  > But this version will not work with any of the 'fork()' backends
  > without further changes to sanei_scsi.c - or 'unforking' the
  > backends ;-)

  forking is such an essential programming technique that I don't think
  we should change anything in this part of the code. However, there
  seem to exist a way to use it with OS/2 because Mustek-Scanners seem
  to work and the mustek backend uses fork for the reader process.

  > USB-Scanners will also not work...

  maybe we can support them when we write a sanei_usb.c provided that
  there is USB support in OS/2.

  > I did not try yet to compile any of the frontends
  > (xscanimage or xcam)
  > I am not shure, but I thought this frontends depend on
  > libsane.dll which I do not know how to compile...

  You can also link the X frontends statically against libsane.a (at
  least on Unix. I don't know howver about the requirements concerning
  gtk and X (does they even exist on OS/2?).

  Thanks for all your information.

  Bye,
  Henning

      --
      Source code, list archive, and docs: http://www.mostang.com/sane/
      To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com

  - Next message: Henning Meier-Geinitz: "assert.h problems with shared libraries"
  - Previous message: Henning Meier-Geinitz: "Re: [PATCH] Re: SANE CVS snapshot (2001-05-30) available"
  - In reply to: Franz Bakan: "Re: Compiling on OS/2"
  - Next in thread: Franz Bakan: "Re: Compiling on OS/2"
  - Reply: Franz Bakan: "Re: Compiling on OS/2"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  This archive was generated by hypermail 2b29 : Thu May 31 2001 - 10:33:54 PDT