Opened 14 years ago

Last modified 7 years ago

#259 closed defect (Fixed)

FreeBSD 6 compiling against incorrect version of OpenSSL

Reported by: mysticone Owned by: nickm
Priority: Low Milestone: 0.1.2.x-final
Component: Core Tor/Tor Version:
Severity: Keywords:
Cc: mysticone Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I'm not sure what versions of tor this affects, but so far it's been a problem with any version that didn't exist in BSD ports. Apparently BSD ports already
makes the necessary changes to the Makefile, so any version installed via ports will work properly.

As I understand it, FreeBSD has a version of OpenSSL included with the base system that is older than the version included in ports. Other programs in the
base system link against the version of OpenSSL included in the base system, and programs installed from ports will link with the one included from ports.
The version of OpenSSL in the base system is installed in /lib, while the ports version is in /usr/local/lib.

When compiling tor from source, whether a stable release, unstable release, or from CVS, the compile will proceed without any warnings or errors. However,
upon running tor, the node is unable to establish connections to any other tor nodes. I couldn't figure out why at first, just lots of TLS errors about broken
connections, until I found out the tor binary linked to the wrong version of OpenSSL. I guess the older version (I'm not sure what version it is) doesn't support
the necessary things.

Anyway, I tried using the configure script to force tor to build using OpenSSL from /usr/local/lib, but it never seemed to work. I'm assuming that the GNU
automake/autoconf/whatever tools simply link with the first version of a needed library it finds. I'm not a programmer nor a developer, so I don't know how
this whole process really works. I did find out, though, that if I add "-rpath=/usr/local/lib" to the LDFLAGS in src/or/Makefile, tor will compile and link
against the proper version of OpenSSL. This is how the BSD port does it, and it took me a little while to figure it out. Upon changing the Makefile and
rebuilding tor, it works like a charm.

I don't know how to permanently fix it, but, in case anyone else is having problems and looks here, at least they'll see this documented. ;)

[Automatically added by flyspray2trac: Operating System: BSD]

Child Tickets

Change History (6)

comment:1 Changed 14 years ago by nickm

Possibly fixed in CVS as of today; we compare SSLeay() against OPENSSL_VERSION when checking for
linker options, and prefer the linker options that give us a match (if we can find any).

This doesn't do much in the case where we have an openssl in /usr and one in /usr/local compiled
from the same version of openssl but with different (and significantly different!) compiler options.
In that case, you'll still need to specify an rpath.

comment:2 Changed 14 years ago by nickm

(Can you let me know whether current CVS works?)

comment:3 Changed 13 years ago by nickm

If nobody tells me whether it works, I'll mark it closed.

comment:4 Changed 13 years ago by mysticone

Sorry I haven't had a chance to mess with it lately. I downloaded the 0.1.1.20 release today and compiled it on my FreeBSD 6 machine. The only option I passed the configure script was --with-prefix=/usr/local. After compiling, I went to src/or and ran ldd on the tor binary. It shows it linking with libssl in /usr/local/lib! So, everything looks good! :)

comment:5 Changed 13 years ago by nickm

flyspray2trac: bug closed.
According to last comment, seems to be fixed.

comment:6 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.