> Can you get a stack trace? See
> https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#ReportBug
> if
> you're not sure how.
Thanks Nick - I have it working now anyway.
What I did:
This gcc on Damnsmallinux is an "extension" built (mounted actually) in
/opt/compile-3.3.5. This also contains a lot of headers and libs corresponding
to lib versions in the dsl base (which contains very few headers), including
headers for quite old openssl static libs. Normally one points LDFLAGS and
CPPFLAGS at these in /opt/compile to provide an enriched build environment.
I had built more a recent openssl and installed it in /opt/tor with the
intention of compiling and running against that.
I had LDFLAGS and CPPFLAGS pointed at both sets of openssl libs.
When I just pointed LDFLAGS and CPPFLAGS at my newer openssl version in
/opt/tor before compiling the segfault on running tor went away.
export LDFLAGS="-L/opt/tor/local/lib -L/opt/tor/lib"
export CPPFLAGS="-I/opt/tor/include -I/opt/tor/local/include"
./configure --prefix=/opt/tor --build=i686
--with-openssl-dir=/opt/tor/local/lib --with-libevent-dir=/opt/tor/lib
Theory: Maybe some version conflict between a shared lib in /opt/compile and on
the base system - one at compile time and the other at runtime? I think
openssl may not have been the culprit however since those are static -
libcrypto.a and libssl.a
