Opened 7 years ago

Closed 7 years ago

#9058 closed defect (fixed)

tor current compile breakage "libor-crypto.a"

Reported by: yancm Owned by:
Priority: Medium Milestone: Tor: 0.2.5.x-final
Component: Core Tor/Tor Version: Tor: unspecified
Severity: Keywords: tor-client netbsd
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Since updating source from HEAD (whatever git calls it's top level) via git I have been unable to compile.

I cleaned, removed Makefile, re-ran autogen and configure....still no joy.

Platform: NetBSD i386 5_Stable

Message:
CCLD src/tools/tor-gencert
src/common/libor-crypto.a(aes.o): In function `aes_new_cipher':
src/common/aes.c:100: undefined reference to `EVP_aes_128_ctr'
* Error code 1

Child Tickets

Change History (6)

comment:1 Changed 7 years ago by nickm

Keywords: tor-client netbsd added
Milestone: Tor: unspecifiedTor: 0.2.5.x-final

Strange! This doesn't look like libor-crypto.a is failing to link -- instead, it looks like tor-gencert is linking libor-crypto.a, but for some reason is not linking a good version of openssl's "libcrypto" component.

Can you run 'make V=1' to find out the command line that's failing?

Is tor-gencert the only thing that fails to link, or do other make targets fail too?

What version of OpenSSL do you have?

comment:2 Changed 7 years ago by yancm

At the moment, this is as far as make gets after a make clean/rm Makefile/autogen/configure. Over the last week I have needed to go through this cycle a couple of times, but this is the first time it did not resolve...

Per your questions:
Q1
# make V=1
make all-am
gcc -g -O2 -D_FORTIFY_SOURCE=2 -fstack-protector-all -Wstack-protector -fwrapv --param ssp-buffer-size=1 -fPIE -Wall -fno-strict-aliasing -pie -z relro -z now -o src/tools/tor-gencert src/tools/tor-gencert.o src/common/libor.a src/common/libor-crypto.a src/common/libcurve25519_donna.a -lm -lz -lssl -lcrypto -lpthread
src/common/libor-crypto.a(aes.o): In function `aes_new_cipher':
src/common/aes.c:100: undefined reference to `EVP_aes_128_ctr'
* Error code 1

Stop.
make: stopped in /usr/local/src/tor
* Error code 1

Stop.
make: stopped in /usr/local/src/tor
#

2
I have the following ssh package installed:
openssl-1.0.1enb1

On NetBSD, packages reside in /usr/pkg/(etc,bin,lib,....)...
We had to modify configure by:
./configure --with-libevent-dir=/usr/pkg
to get it to use my libevent package...
Do we need to do something similar for ssl?
Where is the best place to check to see if the autogen/configure scripts find the right ssl? (There may be a base system ssl?)

comment:3 Changed 7 years ago by nickm

Do we need to do something similar for ssl?

Maybe, if /usr/pkg isn't in the search path by default. (We'd like to migrate to just using pkg-config, but that patch isn't ready yet.)

If you run that command line, but add "-L/usr/pkg/lib" right after the "gcc", does it start working? If so, you could probably work around this issue by specifying LDFLAGS="-L/usr/pkg/lib" manually when you run configure.

Where is the best place to check to see if the autogen/configure scripts find the right ssl? (There may be a base system ssl?)

The output of configure, when it talks about openssl

comment:4 in reply to:  3 Changed 7 years ago by yancm

Replying to nickm:

If you run that command line, but add "-L/usr/pkg/lib" right after the "gcc", does it start working?

Yes it does...

The output of configure, when it talks about openssl

Yep...uses /usr/lib version rather than /usr/pkg/lib

If so, you could probably work around this issue by specifying LDFLAGS="-L/usr/pkg/lib" manually when you run configure.

First I assumed you meant to set that variable in my environment...
I already have:
LD_LIBRARY_PATH (/usr/local/lib /usr/pkg/lib /usr/pkg/lib/mysql)
LD_RUN_PATH (/usr/local/lib /usr/pkg/lib /usr/pkg/lib/mysql)

now I added:
LDFLAGS -L/usr/pkg/lib

and run configure and it still thinks openssl is in /usr/lib

then I tried: ./configure --with-libevent-dir=/usr/pkg LDFLAGS='-L/usr/pkg/lib'
and it still thinks openssl is in /usr/lib

This gets a bit beyond my knowledge. I do not know how to set search paths for configure. Ideally we need to tell it to look in /usr/pkg first then /usr for both libraries and includes. Specific examples would be helpful?

I need to see if I can make the whole compile work as a package...this would be cleaner since a package make includes some built in mechanisms for dealing with specific package dependencies....

I'll see if I can hack on that this weekend...even if you can show me how to patch the current build process...package-afying this is probably the most valuable think I can try if I can find the time to fumble with it...

comment:5 Changed 7 years ago by yancm

It looks like adding -L/usr/pkg/lib to LDFLAGS inside the Makefile fixes it. I still do not understand how to pass this to configure, but it looks like a workaround... I still think I can package-afy tor... I recommend to close this report since it's a platform specific build bug?
--gene

comment:6 Changed 7 years ago by nickm

Resolution: fixed
Status: newclosed

Agreed. The real solution to this kind of annoyance will be getting #6311 finished and merged.

Note: See TracTickets for help on using tickets.