The latest release date is extracted from the NEWS file,
i.e., it depends only on the sources, not the build date.
This is intended to help in creating reproducible builds
by avoiding timestamps. It is also closer to the date of
the contents of the man page than using just the latest
copyright year.
I do not have a perfect solution that works for both a git
clone and a downloaded tar ball. This solution works well
for released tar balls of the ssocr sources.
In order to help creating reproducible builds of ssocr,
do not use the build day of the man page as the date
inside the man page. Instead, use the latest copyright
year of ssocr.
Using the man page build date has always been problematic,
because it is misleading. But I do not have a general
automatic way to maintain the last change date for the
man page that works for both git clones and tar balls.
This seems like an improvement to me. It provides some
idea of how old the man page is, and this date depends
only on the ssocr source code, not the build date.
This should help with one of the two problems reported
in GitHub issue #22.
Since I have used imlib2-config since "the beginning," I prefer
to keep it as long as it is available. But for systems with a
newer Imlib2 version, a fallback to pkg-config is required.
GCC has become too aggressive with its warnings, complaining about more
and more perfectly valid code.
In August 2020 I received a report of GCC 10.1 generating a warning
about strncat:
--------8<--------
cc -D_FORTIFY_SOURCE=2 -Wall -W -Wextra -pedantic -Werror -pedantic-errors -fstack-protector-all -O3 -c -o ssocr.o ssocr.c
In file included from /usr/include/string.h:495,
from ssocr.c:29:
In function ‘strncat’,
inlined from ‘tmp_imgfile’ at ssocr.c:79:12,
inlined from ‘main’ at ssocr.c:454:15:
/usr/include/bits/string_fortified.h:136:10: error: ‘__builtin_strncat’ specified bound depends on the length of the source argument [-Werror=stringop-overflow=]
136 | return __builtin___strncat_chk (__dest, __src, __len, __bos (__dest));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ssocr.c: In function ‘main’:
ssocr.c:67:19: note: length computed here
67 | pattern_len = strlen(dir) + strlen(DIR_SEP TMP_FILE_PATTERN) + 1;
| ^~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [<builtin>: ssocr.o] Error 1
-------->8--------
Basically the same problem has been reported in GitHub issue #15,
"Fails to build on Arm":
--------8<--------
cc -D_FORTIFY_SOURCE=2 -Wall -W -Wextra -pedantic -Werror -pedantic-errors -fstack-protector-all -O3 -c -o ssocr.o ssocr.c
In file included from /usr/include/string.h:495,
from ssocr.c:29:
In function ‘strncat’,
inlined from ‘tmp_imgfile’ at ssocr.c:79:12,
inlined from ‘main’ at ssocr.c:529:15:
/usr/include/arm-linux-gnueabihf/bits/string_fortified.h:136:10: error: ‘__builtin_strncat’ specified bound depends on the length of the source argument [-Werror=stringop-overflow=]
136 | return __builtin___strncat_chk (__dest, __src, __len, __bos (__dest));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ssocr.c: In function ‘main’:
ssocr.c:67:19: note: length computed here
67 | pattern_len = strlen(dir) + strlen(DIR_SEP TMP_FILE_PATTERN) + 1;
| ^~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [<builtin>: ssocr.o] Error 1
-------->8--------
As described in a Red Hat blog post[1], this warning cannot be avoided
without rewriting the code to not use strncat. I do not intend to do so,
instead I just accept that GCC will generate warnings. Thus this commit
removes -Werror and -pedantic-errors from the CFLAGS.
This fixes compilation on a x86_64 Debian Buster (11) GNU/Linux test
system with gcc (Debian 10.2.1-6) 10.2.1 20210110.
This strncat warning is the only warning generated by that gcc version.
[1] I do not link to that blog post here, because it requires JavaScript
to display textual information, which I find unacceptable.
C compilers are getting more aggressive with warnings and are producing
more false positives. While I intend to keep ssocr compiling without
warnings (as in the last 15 years), I do not use the newest C compilers,
but rather the GCC version included in a stable GNU/Linux distribution,
it may take some time for me to encounter those problems myself, and thus
it may take some time for me to work around them.
A user reported a compilation failure due to new warnings in GCC 10.1.
Since I currently use GCC 7.5.0 from Ubuntu 18.04 LTS, I do not see
those warnings yet, and thus cannot test any workarounds yet.
A first investigation into the issue hints at a need to replace valid code
with code invalid for GCC's default C standard version (necessitating
the specification of a newer C standard in the CFLAGS) to work around
said problem. I have no idea if there are additional warnings with GCC
10.1 after working around that one. Since Google blocks my emails to
the reporting user, I cannot even communicate to find this out. Thus any
code changes will have to wait for either a GCC version with additional
warnings arriving in my GNU/Linux distribution, or establishment of a
different communication channel, e.g., a GitHub issue.
This is intended to interfere less (not at all?) with Debian
packaging efforts.
The Debian Upstream Guide says:
"Some projects include a rough /debian directory among source files
to ease bleeding-edge package compilation and installation on Debian
(and derived) systems. While this is a good effort, it is better to
leave it out of the final tarball as it can interfere with debian's
own packaging effort."
I have renamed the directory to "notdebian" to clearly show that this
is not official. Since the Debian packaging system needs the exact name
"debian" for this directory, "notdebian" does not interfere with this.
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 <abates@johncabot.edu>.
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