Opened 16 months ago

Last modified 9 months ago

#26464 new defect

Static cross-compiling for Windows is broken

Reported by: Hello71 Owned by: Hello71
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: 035-triaged-in-20180711, 035-deferred-20190115, 041-proposed
Cc: Actual Points:
Parent ID: #6623 Points:
Reviewer: nickm Sponsor:

Description

two issues:

  1. TOR_OPENSSL_LIBS doesn't include $TOR_LIB_GDI $TOR_LIB_WS32.
  1. openssl checking doesn't include -lz.

IMO, both should be fixed by using pkg-config. however, I don't feel like that much pain, so I just made this hacky patch:

diff --git a/configure.ac b/configure.ac
index 30f8e63ec..15f4058da 100644
--- a/configure.ac
+++ b/configure.ac
@@ -672,15 +672,18 @@ if test "$bwin32" = "true"; then
   # think it's actually necessary.
   TOR_LIB_GDI=-lgdi32
   TOR_LIB_USERENV=-luserenv
+  TOR_LIB_ZLIB=-lz
 else
   TOR_LIB_WS32=
   TOR_LIB_GDI=
   TOR_LIB_USERENV=
+  TOR_LIB_ZLIB=
 fi
 AC_SUBST(TOR_LIB_WS32)
 AC_SUBST(TOR_LIB_GDI)
 AC_SUBST(TOR_LIB_IPHLPAPI)
 AC_SUBST(TOR_LIB_USERENV)
+AC_SUBST(TOR_LIB_ZLIB)
 
 tor_libevent_pkg_redhat="libevent"
 tor_libevent_pkg_debian="libevent-dev"
@@ -812,7 +815,7 @@ AC_ARG_WITH(ssl-dir,
   ])
 
 AC_MSG_NOTICE([Now, we'll look for OpenSSL >= 1.0.1])
-TOR_SEARCH_LIBRARY(openssl, $tryssldir, [-lssl -lcrypto $TOR_LIB_GDI $TOR_LIB_WS32],
+TOR_SEARCH_LIBRARY(openssl, $tryssldir, [-lssl -lcrypto $TOR_LIB_GDI $TOR_LIB_WS32 $TOR_LIB_ZLIB],
     [#include <openssl/ssl.h>
      char *getenv(const char *);],
     [struct ssl_cipher_st;
@@ -833,10 +836,10 @@ if test "$enable_static_openssl" = "yes"; then
    if test "$tor_cv_library_openssl_dir" = "(system)"; then
      AC_MSG_ERROR("You must specify an explicit --with-openssl-dir=x option when using --enable-static-openssl")
    else
-     TOR_OPENSSL_LIBS="$TOR_LIBDIR_openssl/libssl.a $TOR_LIBDIR_openssl/libcrypto.a"
+     TOR_OPENSSL_LIBS="$TOR_LIBDIR_openssl/libssl.a $TOR_LIBDIR_openssl/libcrypto.a $TOR_LIB_GDI $TOR_LIB_WS32 $TOR_LIB_ZLIB"
    fi
 else
-     TOR_OPENSSL_LIBS="-lssl -lcrypto"
+     TOR_OPENSSL_LIBS="-lssl -lcrypto $TOR_LIB_GDI $TOR_LIB_WS32 $TOR_LIB_ZLIB"
 fi
 AC_SUBST(TOR_OPENSSL_LIBS)

Child Tickets

Change History (13)

comment:1 Changed 16 months ago by Hello71

Status: assignedneeds_review

comment:3 Changed 16 months ago by gk

Component: - Select a componentCore Tor/Tor

comment:4 Changed 16 months ago by asn

Reviewer: catalyst

comment:5 Changed 16 months ago by nickm

Milestone: Tor: 0.3.5.x-final

comment:6 Changed 15 months ago by nickm

Keywords: 035-triaged-in-20180711 added

comment:7 Changed 15 months ago by nickm

Reviewer: catalystnickm

comment:8 Changed 15 months ago by nickm

Status: needs_reviewneeds_information

I'm having trouble reproducing the fix here. When I try to cross-compile with "--enable-static-tor", with this patch or without it, it gets stuck on libevent, not openssl.

It runs straight into

configure: error: "You must specify an explicit --with-libevent-dir=x option when using --enable-static-libevent"

whether I specify --with-libevent-dir or not, whether I apply this patch or not.

Do you have a set of example instructions to produce a static build with this patch?

comment:9 Changed 15 months ago by nickm

Also, I think it's inconsistent to use TOR_LIB_ZLIB in this way: in the other cases, TOR_LIB_FOO is defined whenever we have a libFoo that we want to link. But here TOR_LIB_ZLIB is defined only when we have a libz to link, and we are building for windows.

comment:10 Changed 15 months ago by Hello71

I used MXE following the instructions from #26376. I did not pass --enable-static-anything, firstly because I didn't realize those options existed, and secondly, I figure CC=i686-w64-mingw32.static-gcc ought to do everything automatically.

I agree about TOR_LIB_ZLIB being inconsistent though. Personally I still like the idea of using pkg-config for everything, so I posted my idea for that in #6311.

This isn't a big rush, nor is it critical, so if you (pl) decide to accept my plan in #6311, we can just do step 1 at some point and obsolete this (because the old logic wasn't working here anyways).

comment:11 Changed 13 months ago by teor

Parent ID: #6623

comment:12 Changed 12 months ago by Hello71

Status: needs_informationnew

Pending #6311.

comment:13 Changed 9 months ago by nickm

Keywords: 035-deferred-20190115 041-proposed added
Milestone: Tor: 0.3.5.x-finalTor: unspecified

Marking a number of 0.3.5 tickets as possible, maybe even a good idea, for later. Possibly backportable, some of them. But not currently things to do as part of 0.3.5 stabilization.

Note: See TracTickets for help on using tickets.