Opened 8 years ago

Last modified 2 years ago

#4692 needs_revision defect

If only a working static OpenSSL is available, ./configure fails

Reported by: sjmurdoch Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: unspecified
Severity: Normal Keywords: tor-relay autotools linker build
Cc: Actual Points:
Parent ID: #6311 Points:
Reviewer: Sponsor:

Description

If OpenSSL is available, but only the statically linked version works, ./configure will fail. This is because the autoconf test program will be by default built dynamically, at least on Windows, even if --enable-static-openssl is set. The attached patch (appears to) resolve this problem on Windows.

However, the patch doesn't work on MacOS X because passing -static to the compiler causes it to fail with the error "ld: library not found for -lcrt0.o". I presume MacOS X can't produce fully static binaries for whatever reason.

What I'd really like to do is pass "$TOR_LIBDIR_openssl/libssl.a $TOR_LIBDIR_openssl/libcrypto.a" into the link path of the test program built by TOR_SEARCH_LIBRARY(openssl, ...). However, $TOR_LIBDIR_ is being set by TOR_SEARCH_LIBRARY so there is a chicken and egg problem here which I'm not sure how to resolve.

These tests were done on Tor version e4cebb76c5577b1a39b752cc694147e929662c4a.

Child Tickets

Attachments (1)

0001-If-asked-to-use-a-static-OpenSSL-pass-static-when-bu.patch (1.5 KB) - added by sjmurdoch 8 years ago.

Download all attachments as: .zip

Change History (25)

comment:1 Changed 8 years ago by nickm

I think that the only correct way for us to support strange compilation/linking options longer-term is going to involve the ability to override our search behavior with environment options, the way that pkg-config autoconf stuff does. IOW, we should check for variables like OPENSSL_LIBS and OPENSSL_LDFLAGS and OPENSSL_INCS, and let them override our automatically detected stuff.

The attached patch can't actually work, I think: passing "-static" makes not only openssl but _all_ libraries get linked statically, which is not what --enable-static-openssl was supposed to do.

comment:2 Changed 7 years ago by Sebastian

Hrm, maybe the patch still does OK? It only uses -static while linking the configure test example, right?

comment:3 Changed 7 years ago by nickm

Status: newneeds_review

Oh hey, I think you're right. Folks who need to do static builds : please see if you can test this out and see if it helps?

comment:4 Changed 7 years ago by nickm

Milestone: Tor: 0.2.3.x-final

Marking as 0.2.3.x, but backportable.

comment:5 Changed 7 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: 0.2.2.x-final
Status: needs_reviewneeds_revision

Hm. This didn't work for me on fc17: it complained that I didn't have a dlopen. Without this patch, --enable-static-openssl works okay.

That's a regression, so I can't merge it. :/

comment:6 Changed 7 years ago by Sebastian

I haven't tested this patch, sad to hear it breaks on fc. My workaround has been to make sure we always have a static and dynamic openssl around on windows

comment:7 Changed 7 years ago by nickm

Milestone: Tor: 0.2.2.x-finalTor: 0.2.4.x-final

hm. since there's a workaround, I'm okay with deferring this to 0.2.4.x. If somebody comes up with a great simple solution that _does_ work all the places we want to build, it could move back into 0.2.3.x though.

comment:8 Changed 7 years ago by nickm

Keywords: tor-relay added

comment:9 Changed 7 years ago by nickm

Component: Tor RelayTor

comment:10 Changed 6 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

Deferring again; this stuff is important but nasty and usually takes a bunch of iterations to get right. Let's try to remember to pay attention to it early in 0.2.5.

comment:11 Changed 5 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.???

comment:12 Changed 4 years ago by nickm

Milestone: Tor: 0.2.???Tor: 0.2.7.x-final

These might also be worth looking at in 0.2.7

comment:13 Changed 4 years ago by nickm

Keywords: 027-triaged-1-out added

Marking triaged-out items from first round of 0.2.7 triage.

comment:14 Changed 4 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.???

Move *most* 0.2.7-triaged-1-out needs_revision items into 0.2.???. Keep a few based on my sense of the sensible.

comment:15 Changed 4 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.2.8.x-final
Severity: Normal

Users are requesting this feature in #tor-dev, could we get it done in 0.2.8 or 0.2.9?

comment:16 Changed 4 years ago by yawning

Parent ID: #6311

I assume like everything else listed under #6311, this will be fixed in the switch to pkg-config. Setting the parent for tracking purposes.

comment:17 Changed 3 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.???

It is impossible that we will fix all 261 currently open 028 tickets before 028 releases. Time to move some out. This is my first pass through the "needs_revision" and "needs_information" tickets, looking for things to move to ???.

Note that in most cases, if these tickets get the requested revisions done in time for the 0.2.8 merge window, they could get considered for review and merge in 0.2.8.

comment:18 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:19 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:20 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:21 Changed 2 years ago by nickm

Keywords: 027-triaged-in added

comment:22 Changed 2 years ago by nickm

Keywords: 027-triaged-in removed

comment:23 Changed 2 years ago by nickm

Keywords: 027-triaged-1-out removed

comment:24 Changed 2 years ago by nickm

Keywords: autotools linker build added
Note: See TracTickets for help on using tickets.