Some gcc versions do explode if the order of the linker flags are not correct.
One issue was statically building OpenSSL which would require that "-lssl
-lcrypto" be put _before_ the "-lpthread -ldl" flags.
I have not such problem with GCC 10 but does with GCC 9.
Closes#33624
Signed-off-by: David Goulet <dgoulet@torproject.org>
We know there are overflows in curve25519-donna-c32, so we'll have
to have that one be fwrapv.
Only apply the asan, ubsan, and trapv options to the code that does
not need to run in constant time. Those options introduce branches
to the code they instrument.
(These introduced branches should never actually be taken, so it
might _still_ be constant time after all, but branch predictors are
complicated enough that I'm not really confident here. Let's aim for
safety.)
Closes 17983.
On some platforms, the linker is perfectly happy to produce binaries
that won't run if you give it the wrong set of flags. So when not
cross-compiling, try to link-and-run a little test program, rather
than just linking it.
Possible fix for 6173.
First, specify -Werror when we are testing each option; if it causes
a warning to appear, we shouldn't be adding it.
Second, do not attempt to add these options until after we have
found the libraries we want. Previously, I would hit a bug where
the linker hardening options worked fine when we weren't linking
anything, but failed completely once we added openssl or libevent.
This is a matter of making gcc and friends squirm more loudly when
they get an option they don't like (-pedantic) and making clang shut
up with it gets an option it tolerates but doesnt know
(-Qunknown-argument).
Is there no better way?
Oops. We had been telling people to use --with-ssl-dir, which had not worked since 0.2.0.1-alpha: --with-openssl-dir was the one that worked. Make them both work, document --with-openssl-dir, and mark --with-ssl-dir as obsolete. Found by "Dave".
svn:r16625
Write a new autoconf macro to test whether a function is declared. It is suboptimal and possibly buggy in some way, but it seems to work for me. use it to test for a declaration of malloc_good_size, so we can workaround operating systems (like older OSX) that have the function in their libc but do not deign to declare it in their headers. Should resolve bug 587.
svn:r13339
Handle cross-compilation more sanely: avoid most uses of the (never-defined!) CROSS_COMPILE variable; in the one place where we cannot help it, use the correct cross_compiling.
svn:r12945
Do not alter CPPFLAGS until we are actually done with the rest of configure.in: this way, we notice if there are library paths that we are missing.
svn:r10345
More autoconf hacking: use same machinery to find zlib as for openssl and libevent. Have unified library finder include setup for --with variable. Start trying to suggest to the user what packages they should install if finding the library fails.
svn:r9945
Macro-ize our "search for a library and find out how to link against it" code. This will help make our handling of libevent and openssl more similar, and with any luck better. Not pushing to main branch until after 0.1.2.
svn:r9726
