[Tor-BSD] Having issues forcing Tor release 0.2.6.9 to build with update libssl.so.32.0 library
teor
teor2345 at gmail.com
Tue Jun 30 11:20:12 EDT 2015
Hi Seth,
Apologies for the super-long email, but I think we're finally getting to the bottom of this.
As a quick shortcut, does
./configure --with-openssl-dir=/usr/local …
get you linkage to libcrypto and libssl in /usr/local/lib?
(You were using --with-openssl-dir=/usr/local/lib, apologies for not picking this up sooner.)
> On 30 Jun 2015, at 08:19 , Seth <list at sysfu.com> wrote:
>
> On Mon, 15 Jun 2015 01:51:30 -0700, teor <teor2345 at gmail.com> wrote:
>> Can you please provide any configure or make output containing ssl or crypto?
>> What is the entire output in config.log for openssl configuration?
>
> Sorry for the delay, your email response got buried.
No worries.
> Please see attached files for complete log and one with only ssl and crypto strings.
Thanks, these are really helpful.
>> I am aware of issues in previous releases (0.2.5?) on OS X where tor would ./configure openssl based on the location of the first openssl binary in the $PATH, and not the location of the libraries or the SSL directory. I thought these had been fixed, but we might have a regression.
>>
>> Is there an openssl binary in /usr/bin?
>
> $ ls -l /usr/bin/open*
> lrwxr-xr-x 1 root wheel 22 Jun 15 11:49 /usr/bin/openssl -> /usr/local/bin/openssl
> -r-xr-xr-x 1 root bin 498904 Mar 9 03:52 /usr/bin/openssl2.1
>
>> In /usr/local/bin?
>
> $ ls -l /usr/local/bin/open*
> -rwxr-xr-x 1 root wheel 1461810 Jun 15 11:47 /usr/local/bin/openssl
>
>> What is your $PATH when ./configure is called?
>
> /home/<username>/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:.
Thanks, this helps me understand what's going on.
You have an openssl binary in both /usr/bin and /usr/local/bin, and your path has /usr/bin first.
This is the situation which triggers the openssl $PATH bug I referred to.
It looks like the openssl binary is being located based on the first openssl in your path:
configure:5972: checking for openssl
configure:5990: found /usr/bin/openssl
configure:6003: result: /usr/bin/openssl
But the discovered openssl directory is /usr/local/lib:
configure:7793: checking for openssl directory
configure:7846: gcc -std=gnu99 -o conftest -g -O2 -I/usr/local/lib -I${top_srcdir}/src/common -L/usr/local/lib conftest.c -lpthread -lssl -lcrypto >&5
conftest.c: In function 'main':
conftest.c:62: warning: implicit declaration of function 'exit'
conftest.c:62: warning: incompatible implicit declaration of built-in function 'exit'
configure:7846: $? = 0
configure:7868: gcc -std=gnu99 -c -g -O2 -I/usr/local/lib -I${top_srcdir}/src/common conftest.c >&5
configure:7868: $? = 0
configure:7961: result: /usr/local/lib
And ldd's output shows that libcrypto is being linked based on the path passed to ./configure --with-openssl-dir=/usr/local/lib
This looks like either:
* a regression to the 0.2.5 behaviour I discovered on OS X, or
* that the bug was only fixed in 0.2.7.1-alpha, or
* that the --with-openssl-dir= path should be /usr/local rather than /usr/local/lib. (I'm really sorry I didn't pick this up in my first email.)
My suggested solutions below will help me work out which one of these is happening.
>> What is the $PATH used in the openssl configure step? (This may require grepping logs or modifying ./configure)
>
> Not sure I understand. Do you when ./configure was run to build LibreSLL 2.2.0? If so, it would be the same as above.
I was looking for the path that Tor's ./configure uses to try to find an openssl binary.
Based on the logs above, either:
* ./configure is using the $PATH that's passed to it, or
* any modifications ./configure makes to the path are having no effect, or
* ./configure's search for an openssl binary in /usr/local/lib/bin is failing (for obvious reasons).
Again, my suggested solutions below will help me work out which one of these is happening.
>> There may also be an issue with the linker command generated by ./configure:
>>
>> What is $LDFLAGS when ./configure is called?
>
> Same as the ./configure command I posted in beginning of thread: LDFLAGS=-L/usr/local/lib
>
>> What is $CC when ./configure is called?
>
> $ sudo echo $CC
>
> (No value set)
./configure discovers /usr/bin/gcc, which is gcc 4.2.1:
configure:4177: checking for gcc
configure:4193: found /usr/bin/gcc
configure:4204: result: gcc
configure:4433: checking for C compiler version
configure:4442: gcc --version >&5
gcc (GCC) 4.2.1 20070719
…
This is useful for me to know, because I had some concerns this was a clang-specific issue. (It's not.)
>
>> Can you please provide the exact command-line used for linking tor, particularly any -L or -l directives? (This may require grepping logs or modifying a Makefile)
>
> Not sure I understand the question, as I didn't do any manual linking. Only introduced CFLAGS and LDFLAGS when running ./configure
When the tor binary is linked, the order of any -L and -l directives determines exactly which libraries are linked.
From the ldd output, I'm guessing that the command-line looks something like this:
<linker> -L /usr/local/lib -lcrypto -L /usr/lib -lssl
But I can't see how ./configure produces that outcome from the logs your provided. Something really strange is happening.
If you can run a verbose build that shows the linker command used to link the tor binary, that would be helpful.
Can you try:
CC="/usr/bin/gcc -v" ./configure --with-openssl-dir=/usr/local/lib …
If this works, can you please provide the output of make, after the line:
CCLD src/or/tor
This will help me see what arguments are actually being passed to the linker.
For example, on my OS X system, with the latest tor git sources, I see:
(Note that the system OpenSSL on OS X is 0.9.8, which is unsupported by Tor 0.2.7, so I'm using OpenSSL 1.0.2c via MacPorts.)
CC="/opt/local/bin/gcc -v" ./configure --with-libevent-dir=/opt/local --with-openssl-dir=/opt/local
…
make
…
CCLD src/or/tor
…
LIBRARY_PATH=/opt/local/lib/gcc5/gcc/x86_64-apple-darwin14/5.1.0/:/opt/local/lib/gcc5/gcc/x86_64-apple-darwin14/5.1.0/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.10.3' '-v' '-g' '-O2' '-D' '_FORTIFY_SOURCE=2' '-fstack-protector-all' '-Wstack-protector' '-fwrapv' '--param' 'ssp-buffer-size=1' '-fPIE' '-fasynchronous-unwind-tables' '-Wall' '-fno-strict-aliasing' '-Wno-deprecated-declarations' '-L/opt/local/lib' '-L/opt/local/lib' '-pie' '-Zdead_strip' '-o' 'src/or/tor' '-mtune=core2'
/opt/local/libexec/gcc/x86_64-apple-darwin14/5.1.0/collect2 -dynamic -arch x86_64 -dead_strip -macosx_version_min 10.10.3 -pie -weak_reference_mismatches non-weak -o src/or/tor -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib/gcc5/gcc/x86_64-apple-darwin14/5.1.0 -L/opt/local/lib/gcc5/gcc/x86_64-apple-darwin14/5.1.0/../../.. src/or/tor_main.o src/or/libtor.a src/common/libor.a src/common/libor-crypto.a src/common/libcurve25519_donna.a src/ext/ed25519/ref10/libed25519_ref10.a src/common/libor-event.a src/trunnel/libor-trunnel.a -lz -levent -lssl -lcrypto -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v -idsym
collect2 version 5.1.0
/opt/local/bin/ld -dynamic -arch x86_64 -dead_strip -macosx_version_min 10.10.3 -pie -weak_reference_mismatches non-weak -o src/or/tor -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib/gcc5/gcc/x86_64-apple-darwin14/5.1.0 -L/opt/local/lib/gcc5/gcc/x86_64-apple-darwin14/5.1.0/../../.. src/or/tor_main.o src/or/libtor.a src/common/libor.a src/common/libor-crypto.a src/common/libcurve25519_donna.a src/ext/ed25519/ref10/libed25519_ref10.a src/common/libor-event.a src/trunnel/libor-trunnel.a -lz -levent -lssl -lcrypto -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v
…
Library search paths:
/opt/local/lib
/opt/local/lib
/opt/local/lib/gcc5/gcc/x86_64-apple-darwin14/5.1.0
/opt/local/lib/gcc5
/usr/lib
/usr/local/lib
Framework search paths:
/Library/Frameworks/
/System/Library/Frameworks/
…
>> And a quick sanity check:
>>
>> Does tor link entirely to /usr/lib when ./configure --with-openssl-dir=/usr is used?
>
> Yes.
>
> $ ldd /usr/local/bin/tor
> /usr/local/bin/tor:
> Start End Type Open Ref GrpRef Name
> 00000c1110200000 00000c11107c3000 exe 1 0 0 /usr/local/bin/tor
> 00000c138730b000 00000c1387720000 rlib 0 1 0 /usr/lib/libz.so.5.0
> 00000c13a42bf000 00000c13a46e7000 rlib 0 1 0 /usr/lib/libm.so.9.0
> 00000c139fbb1000 00000c139ffbd000 rlib 0 1 0 /usr/lib/libevent.so.4.1
> 00000c13c83cc000 00000c13c882b000 rlib 0 1 0 /usr/lib/libssl.so.32.0
> 00000c131e761000 00000c131ed36000 rlib 0 1 0 /usr/lib/libcrypto.so.32.0
> 00000c13a8db0000 00000c13a91c2000 rlib 0 2 0 /usr/lib/libpthread.so.18.1
> 00000c137dbb8000 00000c137e0a4000 rlib 0 1 0 /usr/lib/libc.so.78.1
> 00000c137f900000 00000c137f900000 rtld 0 1 0 /usr/libexec/ld.so
>
>> What about ./configure without an --with-openssl-dir argument?
>
> $ sudo ./configure --disable-asciidoc --disable-gcc-hardening --sysconfdir=/etc; sudo make check; sudo make install
>
> $ ldd /usr/local/bin/tor
> /usr/local/bin/tor:
> Start End Type Open Ref GrpRef Name
> 0000158897500000 0000158897ac3000 exe 1 0 0 /usr/local/bin/tor
> 0000158ad2d31000 0000158ad3146000 rlib 0 1 0 /usr/lib/libz.so.5.0
> 0000158aa4f01000 0000158aa5329000 rlib 0 1 0 /usr/lib/libm.so.9.0
> 0000158ab7aeb000 0000158ab7ef7000 rlib 0 1 0 /usr/lib/libevent.so.4.1
> 0000158aaf91f000 0000158aafd7e000 rlib 0 1 0 /usr/lib/libssl.so.32.0
> 0000158ab910e000 0000158ab96e3000 rlib 0 1 0 /usr/lib/libcrypto.so.32.0
> 0000158ac1459000 0000158ac186b000 rlib 0 2 0 /usr/lib/libpthread.so.18.1
> 0000158b5cdee000 0000158b5d2da000 rlib 0 1 0 /usr/lib/libc.so.78.1
> 0000158b64600000 0000158b64600000 rtld 0 1 0 /usr/libexec/ld.so<tor-2.6.9-openbsd-5.7-libressl-2.2.0-config.log><tor-2.6.9-openbsd-5.7-libressl-2.2.0-config-ssl-crypto-only.log>
One of the following methods should give you a tor binary that's linked with /usr/local/lib/libssl.so and /usr/local/lib/libcrypto.so. Once I know which method produces a correctly linked tor binary, I'll have enough information to log a bug with the Tor Trac system.
If you do these in order, please feel free to stop at the first successful method. I only need to know how to get correct tor linkage, with the earliest Tor version, and the fewest extra arguments to ./configure.
Using the sources for Tor 0.2.6.9:
1. Using --with-openssl-dir=/usr/local
./configure --with-openssl-dir=/usr/local
(You used /usr/local/lib previously. This could be the issue.)
2. Using --with-openssl-dir=/usr/local with /usr/local/bin first in the path
PATH=/usr/local/bin:$PATH ./configure --with-openssl-dir=/usr/local
Using the latest git sources for Tor 0.2.7.?-alpha:
3. Using --with-openssl-dir=/usr/local with the latest version of tor
./configure --with-openssl-dir=/usr/local
4. Using --with-openssl-dir=/usr/local with the latest version of tor and /usr/local/bin first in the path
PATH=/usr/local/bin:$PATH ./configure --with-openssl-dir=/usr/local
Thanks for bearing with me during this process.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
pgp 0xABFED1AC
https://gist.github.com/teor2345/d033b8ce0a99adbc89c5
teor at blah dot im
OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.nycbug.org/pipermail/tor-bsd/attachments/20150701/bd97c6d5/attachment.bin>
More information about the Tor-BSD
mailing list