aboutsummaryrefslogtreecommitdiff
path: root/configure.ac
AgeCommit message (Collapse)Author
2023-01-12version: Bump version to 0.4.5.16-devTor CI Release
2023-01-12version: Bump version to 0.4.5.16Tor CI Release
2022-12-06version: Bump version to 0.4.5.15-devTor CI Release
2022-12-06version: Bump version to 0.4.5.15Tor CI Release
2022-11-09build: fix -Wstrict-prototypes (Clang 16)Sam James
Clang 16 warns on -Wstrict-prototypes in preparation for C23 which can among other things, lead to some configure tests silently failing/returning the wrong result. Fixes this error: ``` -ignoreme: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes] +ignoreme: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] main () ``` For more information, see LWN.net [0] or LLVM's Discourse [1], gentoo-dev@ [2], or the (new) c-std-porting mailing list [3]. [0] https://lwn.net/Articles/913505/ [1] https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-implicit-function-declaration/65213 [2] https://archives.gentoo.org/gentoo-dev/message/dd9f2d3082b8b6f8dfbccb0639e6e240 [3] hosted at lists.linux.dev. Bug: https://bugs.gentoo.org/879747 Signed-off-by: Sam James <sam@gentoo.org> ---
2022-08-12version: Bump version to 0.4.5.14-devTor CI Release
2022-08-12version: Bump version to 0.4.5.14tor-0.4.5.14Tor CI Release
2022-08-11version: Bump version to 0.4.5.13-devTor CI Release
2022-08-11version: Bump version to 0.4.5.13Tor CI Release
2022-02-04version: Bump version to 0.4.5.12-devTor CI Release
2022-02-04version: Bump version to 0.4.5.12Tor CI Release
2021-11-08Merge branch 'maint-0.3.5' into maint-0.4.5Alexander Færøy
2021-11-06Give an error message if LibreSSL's TLSv1.3 APIs aren't what we needNick Mathewson
From LibreSSL versions 3.2.1 through 3.4.0, our configure script would conclude that TLSv1.3 as supported, but it actually wasn't. This led to annoying breakage like #40128 and #40445. Now we give an error message if we try to build with one of those versions. Closes #40511.
2021-11-05Reverse the direction of the test for openssl 3.0.0Nick Mathewson
Previously the logic was reversed, and always gave the wrong answer. This has no other effect than to change whether we suppress deprecated API warnings. Fixes #40429; bugfix on 0.3.5.13.
2021-10-28version: Missing version update in couple filesDavid Goulet
Signed-off-by: David Goulet <dgoulet@torproject.org>
2021-10-26version: Bump to 0.4.5.11-devDavid Goulet
Signed-off-by: David Goulet <dgoulet@torproject.org>
2021-10-26version: Bump to 0.3.5.17-devDavid Goulet
Signed-off-by: David Goulet <dgoulet@torproject.org>
2021-10-26version: Bump to 0.4.5.11David Goulet
Signed-off-by: David Goulet <dgoulet@torproject.org>
2021-10-26version: Bump to 0.3.5.17David Goulet
Signed-off-by: David Goulet <dgoulet@torproject.org>
2021-08-16Bump version to -devDavid Goulet
Signed-off-by: David Goulet <dgoulet@torproject.org>
2021-08-16Bump version to -devDavid Goulet
Signed-off-by: David Goulet <dgoulet@torproject.org>
2021-08-16Make the version 0.4.5.10, not 0.4.5.10-dev.Nick Mathewson
2021-08-16Make the version 0.3.6.16, not 0.3.6.16-dev.Nick Mathewson
2021-08-13Update version to 0.3.5.16David Goulet
Signed-off-by: David Goulet <dgoulet@torproject.org>
2021-08-13Update version to 0.4.5.10David Goulet
Signed-off-by: David Goulet <dgoulet@torproject.org>
2021-07-06Merge branch 'mr/395' into maint-0.4.5George Kadianakis
2021-07-06Use native timegm when available.Nick Mathewson
Continue having a tor_gmtime_impl() unit test so that we can detect any problems in our replacement function; add a new test function to make sure that gmtime<->timegm are a round-trip on now-ish times. This is a fix for bug #40383, wherein we ran into trouble because tor_timegm() does not believe that time_t should include a count of leap seconds, but FreeBSD's gmtime believes that it should. This disagreement meant that for a certain amount of time each day, instead of calculating the most recent midnight, our voting-schedule functions would calculate the second-most-recent midnight, and lead to an assertion failure. I am calling this a bugfix on 0.2.0.3-alpha when we first started calculating our voting schedule in this way.
2021-06-14Bump to 0.4.5.9-devNick Mathewson
2021-06-14Bump to 0.3.5.15-devNick Mathewson
2021-06-07Bump to 0.4.5.9.Nick Mathewson
2021-06-07Bump to 0.3.5.15.Nick Mathewson
2021-05-10Update to 0.4.5.8-devNick Mathewson
2021-05-07Bump to 0.4.5.8.Nick Mathewson
2021-04-19Merge remote-tracking branch 'tor-gitlab/mr/355' into maint-0.4.5George Kadianakis
2021-04-07Try making our configure.ac script build with AC 2.70.Nick Mathewson
In versions <=2.69, according to the autoconf docs, AC_PROG_CC_C99 is needed with some compilers, if they require extra arguments to build C99 programs. In versions >=2.70, AC_PROG_CC checks for these compilers automatically, and so the AC_PROG_CC_C99 macro is obsolete. So, what can you do if you want your script to work right with both autoconf versions? IIUC, neither including AC_PROG_CC_C99 macro nor leaving it out will give you the right behavior with both versions. It looks like you need to look at the autoconf version explicitly. (Now, the autoconf manual implies that it's "against autoconf philosophy" to look at the autoconf version rather than trying the behavior to see if it works, but they don't actually tell you how to detect recoverably at autoconf-time whether a macro is obsolete or not, and I can't find a way to do that.) So, is it safe to use m4_version_prereq, like I do here? It isn't listed in the autoconf 2.63 manual (which is the oldest version we support). But a mailing list message [1] (which added the documentation back in 2008) implies that m4_version_prereq has been there since "at least back to autoconf 2.59". https://lists.gnu.org/archive/html/autoconf-patches/2008-12/msg00025.html So I think this will work. I am basing this patch against Tor 0.3.5 since, if autoconf 2.70 becomes widespread before 0.3.5 is unsupported, we might need this patch to continue 0.3.5 development. But I don't think we should backport farther than 0.4.5 until/unless that actually happens. This is part of a fix for #40355.
2021-03-16Bump version to 0.4.5.7-devNick Mathewson
2021-03-16Bump to 0.3.5.14-devNick Mathewson
2021-03-15Bump to 0.4.5.7Nick Mathewson
2021-03-15Bump to 0.3.5.14Nick Mathewson
2021-02-23Merge branch 'tor-gitlab/mr/326' into maint-0.4.5David Goulet
2021-02-23Remove mallinfo() from codebaseDavid Goulet
Now deprecated in libc >= 2.33 Closes #40309 Signed-off-by: David Goulet <dgoulet@torproject.org>
2021-02-23Remove mallinfo() from codebaseDavid Goulet
Now deprecated in libc >= 2.33 Closes #40309 Signed-off-by: David Goulet <dgoulet@torproject.org>
2021-02-17Make our configure.ac script use the portable `=` comparisonNick Mathewson
Back in 0.4.5.1-alpha we added an `==` comparison, which isn't portable. Fixes bug #40298; bugfix on 0.4.5.1-alpha.
2021-02-15Bump to 0.4.5.6-devNick Mathewson
2021-02-15Bump to 0.4.5.6.Nick Mathewson
2021-02-03bump to 0.4.4.7-devNick Mathewson
2021-02-03Bump to 0.3.5.13-dev.Nick Mathewson
2021-02-01bump to 0.4.5.5-rc-devNick Mathewson
2021-01-28Merge branch 'maint-0.4.3' into maint-0.4.4David Goulet
2021-01-28Merge branch 'maint-0.3.5' into maint-0.4.3David Goulet