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"

    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
    



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