The spec file gets processed by configure, the version will be filled
in automatically.
To generate an rpm make sure to install rpm-build, then "configure" as you
would usually do, run "make dist", then process the generated tarball
with rpmbuild:
rpmbuild -tb tox-0.0.0.tar.gz
Tested on Fedora 22.
Tox now uses some crypto_pwhash functions that are only available in the
newer libsodium releases; check this in configure to prevent compile
time errors.
From what I see there is a difference between *BSD and Linux when
linking vs. toxcore which has been bulit vs. the NaCl library:
on Linux it only links if NaCl's object files (i.e. randombytes.o) is
present in the linker options, however on *BSD systems this will cause a
linking error, see:
https://github.com/Tox/toxic/issues/31#issuecomment-38224441
This commit makes sure that we do not add the NaCl object files to our
pkg-config settings on *BSD, but do add them on Linux.
My previous attempt that was supposed to disable shared library builds
with nacl had a side effect which basically disabled shared libs for all
configurations.
Eventhough AC_DISABLE_SHARED was used inside an if clause it seemed to
take over in any case.
I could not find a clean way around this, so had to override internal
libtool variables. Will check with the libtool people regarding a
cleaner implementation.
According to sonOfRa sodium_init() has some timing issues on Android.
libsodium people said randombytes_stir() can be used instead:
https://github.com/jedisct1/libsodium/issues/121
sodium_init() stays the default, randombytes_stir() can be enabled by
passing --enable-randombytes-stir to the configure script.
By default libsodium is used. Only if --enable-nacl is specified, then
nacl will be used instead of libsodium.
Pass locations of nacl headers and libraries by using the following
options:
--with-nacl-headers=/home/me/somewhere/nacl-20110221/build/469/include/amd64/
--with-nacl-libs=/home/me/somewhere/nacl-20110221/build/469/lib/amd64/
This update makes sure that the build still works with automake prior to
1.12 and at the same time does not give any warnings or errors with
automake 1.14
This should allow to keep the libtool options all in one place and at
the same time define different options depending on the host.
Made sure that -no-undefined is set only on Win32. Although no side
effects on Linux and OSX have been observed so far, it's probably better
to play it safe; it does not seem to be needed/does not seem to matter on *nix,
only required for Win32.