Open GoogleCodeExporter opened 9 years ago
Is there really a line break between the - and lcrypto
on the link command (just above the error)? That would
explain the errors.
Original comment by roy.fiel...@gmail.com
on 26 Feb 2009 at 8:42
I think that's just an artifact from cutting and pasting the output log.
Original comment by alexprey...@gmail.com
on 27 Feb 2009 at 7:02
What version of openssl do you have installed (run "openssl version")?
Possibly related, I am unable to compile serf HEAD on a Mac OS X 10.4.11 (PPC)
with an updated openssl installed in /usr/local/ssl (0.9.8k).
First, serfmake doesn't support --with-ssl, so it always picks up the system
openssl in /usr/lib (0.9.7l on my old system).
Switching to autoconf, as in
./configure --prefix=/usr/local/serf --with-apr=/usr/local/apr
--with-openssl=/usr/local/ssl
seems to work fine, but linking fails with
/usr/local/apr/build/libtool --silent --mode=link gcc -L/usr/local/apr/lib
-L/usr/local/ssl/lib -R/usr/local/ssl/lib -static -o test/serf_get libserf-0.la
test/serf_get.lo /usr/local/apr/lib/libaprutil-0.la -lexpat -liconv
/usr/local/apr/lib/libapr-0.la -lresolv -lpthread -lz -lssl -lcrypto
/usr/bin/ld: Undefined symbols:
_BIO_clear_flags
_BIO_set_flags
_BIO_test_flags
_SSL_CTX_set_client_cert_cb
collect2: ld returned 1 exit status
make: *** [test/serf_get] Error 1
Original comment by roy.fiel...@gmail.com
on 3 May 2009 at 8:05
This error is due to a mismatch between the OpenSSL headers and the OpenSSL
libraries.
Original comment by justin.e...@gmail.com
on 19 Jul 2009 at 9:00
This sounds like some extra work for config/compile/runtime version checking.
Putting this under a task for our scons conversion work.
Original comment by gstein
on 13 Jul 2011 at 6:41
I think it's possibly related to OS X building/linking against an SDK version
of openssl instead of the one "installed". On OS X, you have your installed
stuff in /usr and it gets updated as necessary when OS X supplies system
updates. The SDK version(s) stay the same. So if you let serf find OpenSSL in
/usr, it finds a version newer than what is in the SDK. I tested this by using
/usr as my OpenSSL location and I got the above error. When I tell serf that
OpenSSL is in /Developer/SDKs/<SDK_YOU_WANT_TO_USE>/usr, everything
compiles/links fine without any errors. In all honesty, I'd expect the OS X
tool chain to handle this but that is obviously not the case. At least you
know a way to work around it.
Original comment by jcscoob...@gmail.com
on 8 Aug 2011 at 6:41
bug#82, I attached rewrite of autotools build system, if you give it a try it
would be great.
Original comment by alon.barlev@gmail.com
on 5 Oct 2011 at 4:14
Original issue reported on code.google.com by
alexprey...@gmail.com
on 26 Feb 2009 at 3:19