[sane-devel] Compilation error on Compaq Tru64
Hi,
On Wed, Nov 20, 2002 at 12:06:55AM +, Major A wrote:
> > Oops. That would be me who is responsible for ab306.c. On the other
> > hand on first sight it maybe an error in the header (?), as I don't
> > see any suspicious changes between SANE 1.0.1 (oldest version in CVS)
> > and now. And I'm sure I ran 2.0.x at that time.
>
> 1.0.2 was successfully installed on the very same machine, everything
> else has remained the same since, including kernel, headers,
> libraries, gcc, binutils.
Ok. I've never tested on Linux/sparc. sanei_ab306.c doesn't seem to be
the reason for the bug because the dif to 1.0.2 shows only the
addition of FreeBSD and some signedness changes. But maybe a change in
config.h is missing a header now?
> > If you have too much time you can have a look at
> > /usr/include/asm/system.h:140 and find out why there is an
> > unterminated string.
>
> I always have too much time :-(
>
> The lines it complains about are of the form
>
> __asm__ __volatile__("
Maybe it doesn't like the string concatenation: "fdsfsdf" \
"fdsfdsfds" \
"fsdfsfsdf" \
> If I omit the -pedantic flag to gcc, it no longer complains about
> this, but about
>
> /usr/include/asm/io.h:107: `sparc_cpu_model' undeclared (first use this
> function)
>
> This is what a grep gives:
>
> /usr/include/asm/auxio.h: switch(sparc_cpu_model) { \
> /usr/include/asm/floppy.h: if((sparc_cpu_model != sun4c &&
> sparc_cpu_model != sun4m) ||
> /usr/include/asm/floppy.h: if(sparc_cpu_model == sun4m) {
> /usr/include/asm/floppy.h:if(sparc_cpu_model == sun4c) {
> /usr/include/asm/io.h: switch(sparc_cpu_model) {
> /usr/include/asm/io.h: printk("mapioaddr: sparc_cpu_model = %d\n",
> sparc_cpu_model);
> /usr/include/asm/io.h: switch(sparc_cpu_model) {
> /usr/include/asm/io.h: printk("unmapioaddr: sparc_cpu_model = %d,
> halt...\n", sparc_cpu_model);
> /usr/include/asm/pgtable.h: switch (sparc_cpu_model){
> /usr/include/asm/pgtable.h: switch (sparc_cpu_model){
> /usr/include/asm/system.h:extern enum sparc_cpu sparc_cpu_model;
> /usr/include/asm/system.h:#define ARCH_SUN4C_SUN4 (sparc_cpu_model==sun4c)
>
> Any ideas?
Sorry, not really. Anyway, the Debian bugtracking systems shows that
there have been (different) errors with this file on Linux/sparc even
with later versions of the kernel. So I guess it's a sparc-specific
kernel bug. Or we are not including a necessary header file.
On the other hand, there is already a check in configure.in, that
should disable asm/io.h if it can't be compiled. Ah, I see: asm/io.h
is included by sys/io.h, so the test isn't effective in this case. We
could also check if including/compiling sys/io.h works but I guess if
linux 2.0/sparc is the only platform with this problem we can ignore it.
Since we use autoconf 2.5, autoconf itself emits a warning if the
header is there but can't be compiled. But that's not in sane 1.0.9.
Bye,
Henning
[sane-devel] Compilation error on Compaq Tru64
> Oops. That would be me who is responsible for ab306.c. On the other
> hand on first sight it maybe an error in the header (?), as I don't
> see any suspicious changes between SANE 1.0.1 (oldest version in CVS)
> and now. And I'm sure I ran 2.0.x at that time.
1.0.2 was successfully installed on the very same machine, everything
else has remained the same since, including kernel, headers,
libraries, gcc, binutils.
> If you have too much time you can have a look at
> /usr/include/asm/system.h:140 and find out why there is an
> unterminated string.
I always have too much time :-(
The lines it complains about are of the form
__asm__ __volatile__("
If I omit the -pedantic flag to gcc, it no longer complains about
this, but about
/usr/include/asm/io.h:107: `sparc_cpu_model' undeclared (first use this
function)
This is what a grep gives:
/usr/include/asm/auxio.h: switch(sparc_cpu_model) { \
/usr/include/asm/floppy.h: if((sparc_cpu_model != sun4c && sparc_cpu_model
!= sun4m) ||
/usr/include/asm/floppy.h: if(sparc_cpu_model == sun4m) {
/usr/include/asm/floppy.h:if(sparc_cpu_model == sun4c) {
/usr/include/asm/io.h: switch(sparc_cpu_model) {
/usr/include/asm/io.h: printk("mapioaddr: sparc_cpu_model = %d\n",
sparc_cpu_model);
/usr/include/asm/io.h: switch(sparc_cpu_model) {
/usr/include/asm/io.h: printk("unmapioaddr: sparc_cpu_model = %d,
halt...\n", sparc_cpu_model);
/usr/include/asm/pgtable.h: switch (sparc_cpu_model){
/usr/include/asm/pgtable.h: switch (sparc_cpu_model){
/usr/include/asm/system.h:extern enum sparc_cpu sparc_cpu_model;
/usr/include/asm/system.h:#define ARCH_SUN4C_SUN4 (sparc_cpu_model==sun4c)
Any ideas?
Andras
===
Major Andras
e-mail: and...@users.sourceforge.net
www:http://andras.webhop.org/
===
[sane-devel] Compilation error on Compaq Tru64
Hi, On Tue, Nov 19, 2002 at 02:31:12PM +, Major A wrote: > This is the error: > > gcc -c -DHAVE_CONFIG_H -I. -I. -I../include -I../include -D_GNU_SOURCE > -DPATH_SANE_CONFIG_DIR=/usr/local/sane/etc/sane.d > -DPATH_SANE_DATA_DIR=/usr/local/sane/share -DV_M > AJOR=1 -DV_MINOR=0 -g -O2 -W -Wall -Wcast-align -Wcast-qual > -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type > -Wstrict-prototypes -pedantic -ansi > sanei_ab306.c -fPIC -DPIC -o sanei_ab306.lo > In file included from /usr/include/asm/io.h:9, > from /usr/include/sys/io.h:27, > from sanei_ab306.c:53: > /usr/include/asm/system.h:140: unterminated string or character constant > [repeated a number of times] Oops. That would be me who is responsible for ab306.c. On the other hand on first sight it maybe an error in the header (?), as I don't see any suspicious changes between SANE 1.0.1 (oldest version in CVS) and now. And I'm sure I ran 2.0.x at that time. Well, as nobody else ever complained, it may be a bug in one single kernel version or just nobody else uses 2.0.x anymore. If you have too much time you can have a look at /usr/include/asm/system.h:140 and find out why there is an unterminated string. Bye, Henning
[sane-devel] Compilation error on Compaq Tru64
> Oh. That's because of sanei_scsi.c? We should add a hint in > README.linux. This is the error: gcc -c -DHAVE_CONFIG_H -I. -I. -I../include -I../include -D_GNU_SOURCE -DPATH_SANE_CONFIG_DIR=/usr/local/sane/etc/sane.d -DPATH_SANE_DATA_DIR=/usr/local/sane/share -DV_M AJOR=1 -DV_MINOR=0 -g -O2 -W -Wall -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -pedantic -ansi sanei_ab306.c -fPIC -DPIC -o sanei_ab306.lo In file included from /usr/include/asm/io.h:9, from /usr/include/sys/io.h:27, from sanei_ab306.c:53: /usr/include/asm/system.h:140: unterminated string or character constant [repeated a number of times] There could be something in sanei_scsi.c as well, but it doesn't get that far. This is kernel 2.0.35. Note that this is 1.0.9-pre2, haven't tried the released version, but it shouldn't be much different. > Well, if I remeber correctly, my 16 MB computer wen about 40 MB into > swap when compiling SANE :-). I had to connect an external SCSI drive as swap when I compiled 1.0.2 a long time ago. Andras === Major Andras e-mail: and...@users.sourceforge.net www:http://andras.webhop.org/ ===
[sane-devel] Compilation error on Compaq Tru64
Hi, On Tue, Nov 19, 2002 at 01:17:36AM +, Major A wrote: > I can't beat your 386 either, but here a pretty slow one: > > iPAQ H3650, also from the HP TestDrive, 195MHz StrongARM-1110, 32MB > RAM. It configures like this: Oh, I missed that one when using the testdrive. > after which the actual build is > > real42m50.703s > user32m47.140s > sys 3m51.420s Not too bad. > It seems to build without errors. Sorry I couldn't test anything on > it, maybe we should ask HP to connect a USB scanner or so? They seem to have added a webcam but I didn't have a look at it. As SANE 1.0.9 is in Debian sid, we can assume that it compiles on all the Linux platforms Debina supports: Alpha, ARM, HP PA-RISC, Intel x86, Intel IA-64, Motorola 680x0, MIPS, MIPS (DEC), PowerPC, IBM S/390, SPARC. However, there is still a bug report about SCSI on Linux/SPARC in the TODO list. > I originally wanted to give you a real killer slug but gave up on it: > a 40MHz SPARCstation 1+ from 1988 with 16MB RAM running diskless as a > SANE server (1.0.2 at the moment). The two problems I had compiling is > that current SANE doesn't like the linux 2.0.x header files still on > that machine, Oh. That's because of sanei_scsi.c? We should add a hint in README.linux. > and that 16MB isn't enough for some of the backends (and linux 2.0.x > can't swap to NFS). It would have taken a really long time though. Well, if I remeber correctly, my 16 MB computer wen about 40 MB into swap when compiling SANE :-). Bye, Henning
[sane-devel] Compilation error on Compaq Tru64
Henning, > On the other hand, they really have nice computers: > > AlphaServer ES45, 4@1GHz, Tru64 > > time make -j4: > real 0m48.473s > user 0m39.115s > sys 0m31.299s > > Slightly faster than yours :-) Well, I want to have one of those :-) > Quite fast if you consiere, that it's used by quite a lot of users. I'm sure I can't beat that today (although my next PC probably will -- in a few years' time). I can't beat your 386 either, but here a pretty slow one: iPAQ H3650, also from the HP TestDrive, 195MHz StrongARM-1110, 32MB RAM. It configures like this: enabling DC210/DC240 backends disabling CANON_PP backend (failed to find required libieee1284 version) disabling HPSJ5S backend (failed to find required libieee1284 version) disabling GPHOTO2 backend (not requested, or failed to find gphoto2-config or JPEG lib) disabling PINT backend enabling QuickCam backend enabling Video4Linux backend enabling NET backend disabling SM3600 backend enabling SnapScan backend in real3m38.541s user0m43.970s sys 0m41.420s after which the actual build is real42m50.703s user32m47.140s sys 3m51.420s It seems to build without errors. Sorry I couldn't test anything on it, maybe we should ask HP to connect a USB scanner or so? I originally wanted to give you a real killer slug but gave up on it: a 40MHz SPARCstation 1+ from 1988 with 16MB RAM running diskless as a SANE server (1.0.2 at the moment). The two problems I had compiling is that current SANE doesn't like the linux 2.0.x header files still on that machine, and that 16MB isn't enough for some of the backends (and linux 2.0.x can't swap to NFS). It would have taken a really long time though. Oh, BTW, the HP iPAQ has its clock set to 1934 for some reason, sure it's way ahead of its time. Andras === Major Andras e-mail: and...@users.sourceforge.net www:http://andras.webhop.org/ ===
[sane-devel] Compilation error on Compaq Tru64
Hi, On Wed, Nov 13, 2002 at 03:13:32PM +, Major A wrote: > After all that, why should I trust in HP's competence in network > maintenance and security? :-( Well, there are quite a few problems on these systems. NFS hangs sometimes, some machines are frozen. On the other hand, it's a good target for hackers, I guess :-) > And yes, it's Tru64 that has buffer overflows in xauth and lpd, and > that supplies a SUID root dtterm that segfaults when run in fvwm. Well, I also don't like that I have to do all kind of tricks to get sane working (compiling my own make, LD_LIBRARY_PATH etc.) On the other hand, they really have nice computers: AlphaServer ES45, 4@1GHz, Tru64 time make -j4: real 0m48.473s user 0m39.115s sys 0m31.299s Slightly faster than yours :-) Well, I want to have one of those :-) Quite fast if you consiere, that it's used by quite a lot of users. > > Yes, I remember. I think I found the problem: config.h defines > > u_int8_t and others and so the lines in sys/bitypes.h look like this > > after macro expansion: > > > > typedef unsigned char unsigned char, something; > > Shouldn't config.h be included after all system headers? Is there any > reason for not doing that? I think that breaks other systems. > Then we can either make the SANE typedefs conditional or simply > #undef the types we redefine. Fixed in CVS. There was just an #include missing that needs to be set when these u_int types are only in sys/bitypes.h. I had to increase the minimum autoconf version to 2.50 to get it working cleanly. Bye, Henning
[sane-devel] Compilation error on Compaq Tru64
Hi, On Wed, Nov 13, 2002 at 01:28:58PM +, Major A wrote: > > I'm trying to compile sane-backends-1.0.9 on some of the HP test > > machines (see http://testdrive.hp.com/). Until now, the tests were > > rather successful. Compilation works on: > > How the f... did you connect to them? I can't get a route to any of > the machines, neither from Britain nor from Germany. I've told them > 10 times, they don't respond. The have a rather restrictive firewall setup. Looks like only telnet and ftp goes through, not even ssh or ping. I'm using Telekom/T-online DSL. No problems with most testdrives, but some seem to be down. Traceroute goes that way: traceroute to spe152.testdrive.hp.com (192.233.54.152), 30 hops max, 38 byte packets [...] 4 Vienna-gw12.USA.net.DTAG.DE (62.156.131.190) 150.425 ms 150.911 ms 150.126 ms 5 so-2-0-0.asbnva1-hcr1.bbnplanet.net (4.25.153.49) 151.562 ms 151.363 ms 150.809 ms 6 so-6-0-0.washdc3-nbr1.bbnplanet.net (4.24.11.249) 150.232 ms 150.942 ms 151.358 ms 7 so-7-0-0.washdc3-nbr2.bbnplanet.net (4.24.10.30) 152.237 ms 152.455 ms 152.797 ms 8 p9-0.phlapa1-br2.bbnplanet.net (4.24.10.186) 152.107 ms 152.345 ms 150.852 ms 9 p15-0.phlapa1-br1.bbnplanet.net (4.24.10.89) 148.738 ms 147.231 ms 148.118 ms 10 p13-0.nycmny1-nbr2.bbnplanet.net (4.24.10.178) 148.189 ms 149.766 ms 149.939 ms 11 so-4-0-0.bstnma1-nbr2.bbnplanet.net (4.24.6.49) 153.186 ms 154.626 ms 153.746 ms 12 so-7-0-0.bstnma1-nbr1.bbnplanet.net (4.24.10.217) 156.660 ms 157.096 ms 156.376 ms 13 p2-0.bstnma1-cr1.bbnplanet.net (4.24.4.210) 152.522 ms 153.674 ms 153.494 ms 14 p0-0-0.cpqtay.bbnplanet.net (4.24.80.198) 158.489 ms 161.049 ms 160.919 ms 15 us-zma-r04.zma.compaq.com (192.208.49.14) 153.810 ms 154.571 ms 156.502 ms 16 * * * [...] > > Tru64 Unix 5.1A/Alpha/cc: > > Compilation results in: > > > > Looks like cc can't handle its own include file? Anyone any ideas? > > I reported this one a while ago (just before the 1.0.9 release). I > thought it's just our installation of Tru64, but if even HP does it > wrong, then it probably isn't. Yes, I remember. I think I found the problem: config.h defines u_int8_t and others and so the lines in sys/bitypes.h look like this after macro expansion: typedef unsigned char unsigned char, something; We have already a workaround for this problem, but the code in config.h was removed when we started using autoheader. I'll se how this can be fixed. Bye, Henning
[sane-devel] Compilation error on Compaq Tru64
> > How the f... did you connect to them? I can't get a route to any of > > the machines, neither from Britain nor from Germany. I've told them > > 10 times, they don't respond. > > The have a rather restrictive firewall setup. Looks like only telnet > and ftp goes through, not even ssh or ping. I'm using Telekom/T-online > DSL. No problems with most testdrives, but some seem to be down. OK, thanks. Telnet seems to work now (it didn't yesterday). It's kind of stupid that they don't allow ssh -- ssh used to work. > Traceroute goes that way: > [...] > 15 us-zma-r04.zma.compaq.com (192.208.49.14) 153.810 ms 154.571 ms > 156.502 ms > 16 * * * A week ago, in fact even before they moved the machines, there was a recursive route between us-zma-r04 and us-zma-r01. After all that, why should I trust in HP's competence in network maintenance and security? :-( And yes, it's Tru64 that has buffer overflows in xauth and lpd, and that supplies a SUID root dtterm that segfaults when run in fvwm. > Yes, I remember. I think I found the problem: config.h defines > u_int8_t and others and so the lines in sys/bitypes.h look like this > after macro expansion: > > typedef unsigned char unsigned char, something; Shouldn't config.h be included after all system headers? Is there any reason for not doing that? Then we can either make the SANE typedefs conditional or simply #undef the types we redefine. Andras === Major Andras e-mail: and...@users.sourceforge.net www:http://andras.webhop.org/ ===
[sane-devel] Compilation error on Compaq Tru64
... perhaps it does not apply to HP-UX 11.X, but on 10.X it is generally a good idea to include the compiler option "-Ae". Ulrich Deiters
[sane-devel] Compilation error on Compaq Tru64
Hi, I'm trying to compile sane-backends-1.0.9 on some of the HP test machines (see http://testdrive.hp.com/). Until now, the tests were rather successful. Compilation works on: Linux 2.4/Alpha/gcc 2.95.4 Linux 2.4/IA64/gcc 2.96 FreeBSD 4.7/Alpha/gcc 2.95.4 NetBSD 1.6/Alpha/gcc 2.95.3 HP-UX 11.22/IA64/HP cc also works, but for some reason, the sane-config script isn't executable, so the configuration of sane-frontends fails. Tru64 Unix 5.1A/Alpha/cc: Compilation results in: cc -c -g -DHAVE_CONFIG_H -I. -I. -I../include -I../include -D_GNU_SOURCE -DPATH_SANE_CONFIG_DIR=/usr/local/etc/sane.d -DPATH_SANE_DATA_DIR=/usr/local/share -DV_MAJOR=1 -DV_MINOR=0 -DBACKEND_NAME=net -DLIBDIR=/usr/local/lib/sane net.c -DPIC -o net.lo cc: Error: /usr/include/sys/bitypes.h, line 89: Invalid declarator. (declarator) typedef unsigned charu_int8_t, u_int8m_t; -^ cc: Error: /usr/include/sys/bitypes.h, line 91: Invalid declarator. (declarator) typedef unsigned short u_int16_t, u_int16m_t; -^ cc: Error: /usr/include/sys/bitypes.h, line 93: Invalid declarator. (declarator) typedef unsigned intu_int32_t, u_int32m_t; -^ Looks like cc can't handle its own include file? Anyone any ideas? The OpenBSD/Alpha and Linux/parisc testdrives doesn't seem to work currently. I'll send an update for the platforms page later. Bye, Henning
[sane-devel] Compilation error on Compaq Tru64
> I'm trying to compile sane-backends-1.0.9 on some of the HP test > machines (see http://testdrive.hp.com/). Until now, the tests were > rather successful. Compilation works on: How the f... did you connect to them? I can't get a route to any of the machines, neither from Britain nor from Germany. I've told them 10 times, they don't respond. > Tru64 Unix 5.1A/Alpha/cc: > Compilation results in: > > Looks like cc can't handle its own include file? Anyone any ideas? I reported this one a while ago (just before the 1.0.9 release). I thought it's just our installation of Tru64, but if even HP does it wrong, then it probably isn't. A while ago, a SunOS UltraSPARC here at university used to "I/O error" on one of the backends -- reproducibly. I hate commercial software! Andras === Major Andras e-mail: and...@users.sourceforge.net www:http://andras.webhop.org/ ===
