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.
At least on still supported Debian and Ubuntu GNU/Linux systems,
both pkg-config and imlib2-config can be used to determine the
LDFLAGS needed to link against Imlib2. Current upstream Imlib2
no longer provides imlib2-config, but only pkg-config data.
GitHub user "watkit" reported to have needed
make CPPFLAGS=-I/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/Tk.framework/Versions/8.5/Headers/
to build ssocr on a 2020 m1 Mac mini.
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.
There have been issues with the basic security features a modern C
compiler should provide, hindering compilation of ssocr. One way to work
around those is to disable use of the broken features. Another way is
to use a quality C compiler, e.g., a stable GCC release.
All "common" tools used to build ssocr have been part of GNU/Linux
distribtuions for decades. But since more people want to build ssocr
on non-GNU systems it might be helpful to hint at where to find the
common utility programs:
- some are used in a POSIX compatible way
- some are part of GNU
- then there are others
- 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
Erik Auerswald