* add `ltc` wrapper script for installed demos
* rework demos/CMakeLists.txt and add some more bells and whistles
* prefix installed demos with `ltc-`
Currently this makes the standard makefiles and CMake results diverge, but
we can fix that later if required.
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
* use a separate `libtomcrypt` folder to install the headers to
* use `INCPATH` and `LIBPATH` when installing `libtomcrypt.pc`
* fix `libtomcrypt.pc` generation for `makefile.unix`
This fixes#625
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
`aes_desc` and `aes_enc_desc` now do auto-detection of the best suitable
AES implementation for the platform.
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
When building libtomcrypt with rlibtool instead of libtool it will fail
when rlibtool fails to parse the generated libtool which does not exist.
Since rlibtool should be the default choice for most slibtool users in
the future this patch will use slibtool-shared instead which will
correctly build the shared library.
This could also help build the shared library on additional targets and
hosts where the stock libtool does not have shared libraries enabled.
@rofl0r @ [1]
"...still it's unusual/unexpected to embed DESTDIR in LIBPATH
etc. where this could hickup is when for example hardcoded paths need
to be embedded into the resulting binary. for example, in the
netbsd-curses makefile i linked earlier, such a case would be reference
to the terminfo DB location, which is derived from PREFIX.
other possible cases might be stuff that dlopen()s its own libs using an
absolute path, or uses other data files. for such a case a contributor
would typically re-use DATAPATH oslt and put it into CPPFLAGS or write
it into a header, to find the required files. when now these paths have
DESTDIR in them too, this will not work. thus it is good practice to use
$(DESTDIR) only in install targets, and keep it out of other vars."
[1] 8e29a6061f (commitcomment-22678488)
This closes#232
when building packages (e.g. for openSUSE Linux)
(random) filesystem order of input files
influences ordering of functions in the output,
thus without the patch, builds (in disposable VMs) would differ.
See https://reproducible-builds.org/ for why this matters.
