This is the first step towards support of different character sets.
Different character sets are intended to be used to e.g. select
between '6' and 'b', but also to receive an error if e.g. a decimal
display is recognized as a hexadecimal digit.
The ssocr code itself uses math.h and thus libm. This library has been
linked to via recursive linking or the requirements of Imlib2 before
this commit. According to a report from Arne Wichmann this does not work
in all environments. While I do not know the exact circumstances under
which this problem occurs, adding -lm to the linker step is correct,
because ssocr uses it. It is incorrect to rely on Imlib2 to pull this in.
- use optimization level -O3, which is supported by both gcc and clang
- removed a set of unnecessary parenthesis
- added info about 'brew' on Mac OS X to INSTALL file
bumped version number to 2.13.3
This should improve compatibility for systems with Imlib2 installed
in non-standard places, e.g. Mac OS X.
On Debian GNU/Linux this results in some warnings when building a .deb:
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/ssocr/usr/bin/ssocr was not linked against libdl.so.2 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/ssocr/usr/bin/ssocr was not linked against libz.so.1 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/ssocr/usr/bin/ssocr was not linked against libX11.so.6 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/ssocr/usr/bin/ssocr was not linked against libfreetype.so.6 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/ssocr/usr/bin/ssocr was not linked against libXext.so.6 (it uses none of the library's symbols)
I'm ignoring this. Special local adaptations like this have no place in
a general build system. A dedicated Debian package might apply a local patch
to strip these dependencies. This could result in a non-working ssocr as
at least libdl is actually needed by Imlib2 to load images.
FreeBSD and Mac OS X don't know 'date -I', but do know 'date +%F' with
'%F' equivalent to '%Y-%m-%d'. POSIX knows neither '-I' nor '%F', but
just '%Y-%m-%d', so use the latter.
Problem reported by Alan Bates <[email protected]>.
Build on recent Ubuntu systems would fail, because the --as-needed linker
option (enabled by default on these systems) needs a special argument
order for ld to work correctly.
(see http://www.gentoo.org/proj/en/qa/asneeded.xml)
Use LDLIBS instead of LDFLAGS to list needed libraries. See GNU Make docs
and http://www.roland-illig.de/articles/article-1.html for rationale.
Bumped version number to 2.9.8, so I can tell the users having build
problems to upgrade to this version.
- no functional changes
- this is another step towards refactoring the recognition algorithm
- this is another step towards factoring out the image access routines to
ultimately replace Imlib2 by something else (e.g. gd)
Erik Auerswald