bug-ocrad
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-ocrad] Re: ocrad-0.7 build feedback


From: Antonio Diaz
Subject: [Bug-ocrad] Re: ocrad-0.7 build feedback
Date: Fri, 13 Feb 2004 17:57:05 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4) Gecko/20030811

Thanks for your feedback.

Nelson H. F. Beebe wrote:
Also, there is a problem in Makefile.in: it is not obeying settings of
CC and CXX made at configure time, but instead is forcing builds with
g++.  Makefile.in MUST have

CC = @CC@
CXX = @CXX@

configure will supply suitable values, defaulting to gcc and g++ if
they are not otherwise set.

Compatibility with non GNU systems is, just now, not a priority for ocrad. Just as an info page was not a priority for ocrad-0.1. Ocrad does not use autoconf, and I don't know how to detect wathever compiler a system has. For now you have to edit the makefile or use the method explained in the INSTALL file:
        ./configure
        make CXX=your_compiler_name ...


Here is a summary of the problems:

------------------------------------------------------------------------
Machinetype:            IBM RS6000 43P-132 (133 MHz);  AIX 4.2
g++  -Wall -W -O2 -c -o bitmap.o bitmap.cc
bitmap.cc: In function `char {anonymous}::pbm_getrawbyte(FILE *)':
bitmap.cc:32: parse error before `('
bitmap.cc:31: warning: unused parameter `struct FILE * f'
bitmap.cc: In method `void Bitmap::save(FILE *, char = '4') const':
bitmap.cc:552: parse error before `('
bitmap.cc:552: parse error before `)'
bitmap.cc:552: parse error before `)'
bitmap.cc:553: parse error before `('
bitmap.cc:565: parse error before `('
bitmap.cc:567: parse error before `('
bitmap.cc:570: confused by earlier errors, bailing out
make: *** [bitmap.o] Error 1

line  32:  int ch = std::getc( f );
line 552:        if( col % step == step - 1 ) ++y;
line 553:        }
line 565:  std::fprintf( f, "P%c\n%d %d\n", filetype, _width, _height );
line 567:  if( filetype == '1' )

Sorry, I can't see any error in these lines of ocrad. Is your C++ library defining macros it shouldn't?


------------------------------------------------------------------------
Machinetype:            Intel Pentium II (2 CPUs, 450 MHz);       FreeBSD 4.4.0

g++  -Wall -W -O2 -c -o ucs.o ucs.cc
In file included from ucs.cc:20:
ucs.h:105: parse error before `!'
ucs.h:106: parse error before `!'
ucs.h:107: parse error before `!'
ucs.h:110: parse error before `!'
ucs.h:111: parse error before `!'
ucs.cc:149: parse error before `('
ucs.cc:155: parse error before `('
ucs.cc:161: parse error before `('
ucs.cc:164: ANSI C++ forbids declaration `code' with no type
ucs.cc:164: implicit declaration of function `int base_letter(...)'
ucs.cc:165: parse error before `return'
ucs.cc: In function `static bool UCS::islower_small(int)':
ucs.cc:171: parse error before `('
ucs.cc:179: confused by earlier errors, bailing out
make: *** [ucs.o] Error 1

FreeBSD uses g++ 2.95. Ocrad don't support it. Please, stop complaining about failed compiles with g++ 2.9x and upgrade.


------------------------------------------------------------------------
Machinetype:            SGI Origin/200-4 (180 MHz) (4 CPUs); IRIX 6.5
g++  -Wall -W -O2 -c -o main.o main.cc
main.cc: In function `int main(int, char**)':
main.cc:220: error: `no_argument' undeclared (first use this function)
main.cc:220: error: (Each undeclared identifier is reported only once for each
   function it appears in.)
main.cc:221: error: `required_argument' undeclared (first use this function)
main.cc:234: error: elements of array `option long_options[]' have incomplete
   type
main.cc:234: error: storage size of `long_options' isn't known
main.cc:237: error: `getopt_long' undeclared (first use this function)
main.cc:218: error: storage size of `long_options' isn't known
make: *** [main.o] Error 1


Ocrad uses the function 'getopt_long' defined by GNU libc. As stated in the file INSTALL, you need "a C library compatible with GNU libc".


In short:
Ocrad is written in standard C++.
Ocrad needs g++ 3.x and glibc.
Perhaps someday this will change, but compatibility is not an issue now.


Regards.
Antonio Diaz, GNU Ocrad author and maintainer.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]