1. 07 Apr, 2021 1 commit
    • Nick Mathewson's avatar
      Try making our configure.ac script build with AC 2.70. · 02816d60
      Nick Mathewson authored
      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
      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".
      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.
  2. 16 Mar, 2021 3 commits
  3. 15 Mar, 2021 3 commits
  4. 23 Feb, 2021 2 commits
  5. 17 Feb, 2021 1 commit
  6. 15 Feb, 2021 2 commits
  7. 03 Feb, 2021 3 commits
  8. 01 Feb, 2021 1 commit
  9. 28 Jan, 2021 4 commits
  10. 22 Jan, 2021 2 commits
  11. 14 Jan, 2021 1 commit
  12. 12 Jan, 2021 1 commit
  13. 11 Jan, 2021 1 commit
  14. 11 Dec, 2020 1 commit
    • David Goulet's avatar
      configure: Revert back the static libevent path · 15b0d30a
      David Goulet authored
      From c618c4f2, we changed the static
      libevent.a path to be able to use the git repository or tarball directly but
      that broke the "make install" setup that Tor Browser is using with Android.
      In other words, the git repository and tarball put the "libevent.a" in
      ".libs/" where "make install" puts it in "lib/".
      Using the --with-libevent-dir=..., which is mandatory for static libevent,
      autoconf will take the path and use it for the includes (-I) and library (-L)
      for which if it finds a "include/" and a "lib/" in the root, it will use
      However, with the git repo or tarball, the "lib/" doesn't exists thus autoconf
      sets the library search path to be at the root and thus fails to find the
      libevent.a in ".libs/".
      This is a whole lot more work to make both cases work in our configure.ac thus
      I'm reverting the change here to the Tor Browser case works again and the work
      around for others is to either symlink the libevent.a at the root or use a
      temporary make install directory.
      One long term fix here would likely be to ask libevent to symblink the .a into
      the root along the .la files and likely do the same for .so. Or, use the
      "lib/" structure to contain the .a + .so files. Would be better than doing
      ninji-tsu in our configure.ac
      Fixes #40225
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
  15. 08 Dec, 2020 1 commit
    • David Goulet's avatar
      configure: Fix the --enable-static-tor switch · c618c4f2
      David Goulet authored
      The "-static" compile flag was set globally which means that all autoconf test
      were attempting to be built statically and lead to failures of detecting
      OpenSSL libraries and others.
      This commit adds this flag only to the "tor" binary build.
      There is also a fix on where to find libevent.a since it is using libtool, it
      is in .libs/.
      At this commit, there are still warnings being emitted that informs the user
      that the built binary must still be linked dynamically with glibc.
      Fixes #40111
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
  16. 23 Nov, 2020 1 commit
  17. 21 Nov, 2020 1 commit
  18. 12 Nov, 2020 4 commits
  19. 09 Nov, 2020 3 commits
  20. 03 Nov, 2020 1 commit
  21. 01 Nov, 2020 2 commits
  22. 30 Oct, 2020 1 commit