Randall DuCharme wrote:
Amos wrote:
Maybe this would be the better one if it works:
AC_CHECK_LIB(crypt, crypt, [CRYPTLIB=" -lcrypt "])
AC_CHECK_LIB(md5, MD5Init, [CRYPTLIB+=" -lmd5 "])
This works fine. (still learning how to use these GNU auto-tools.
I am a C/UNIX developer by profession but don't use GNU tools
other than GCC occasionally. Thanks for the help and for your
patience!)
If there were any other changes beyond the patch I sent and the
above could you send me a patch back and I'll queue it for any
future 26 releases.
No changes other than your patch, copy/paste amendment to it, and
the above configure.in addition. I noticed something though and I'm
not certain of the desired behavior. If I use the --enable-ssl flag
openssl is found and it appears to be enabled (looking at autoconf.h)
Running ldd against the squid binary shows that it's linked against
the openssl libs. The interesting thing is that I don't get any
of those MD5 conflict messages like I thought I would. Without the
--enable-ssl flag the Solaris MD5 header and library are used. If I
provide the --with-openssl=, I can use an alternate OpenSSL
installation ( SunStudio-built and aggressively optimized ) Is this
the desired (new) behavior? Running configure --help says that
--enable-ssl enables gatewaying support using OpenSSL so I'm assuming
that it is. I'm just wanting to be sure that the OS's support
is functioning correctly. What's the best way to thoroughly test
this?
It is. OpenSSL is the currently preferred library. Any alteration in
that would require performance testing on all OS that provide their own
(just this Solaris10 so far, but maybe others later) to prove that its
better than the well-known OpenSSL code.
As for the testing. I'm not too sure myself. Performance and
benchmarking are largely outside my experience as a developer. I come at
things from an HCI/CHI and Architecture design approach.
I'm not quite as lucky with 3.0.RC1 yet.
Okay. That looks like another seperate problem than MD5.
For some reason you have "-Wl,-R -Wl,/usr/sfw/lib/amd64"
twice times at the end of the g++ parameters, that looks to be
the problem. Are you manually setting those flags or leaving
to the autotools?
I was setting -L and -R flags in in the LDFLAGS env variable during
configure since with GCC I often have problems with the runtime
linker not being able to find libraries and trying to use 32 bit
libraries when doing a 64 bit build if I don't set them. I have
removed all -L and -R paths (and I do not set LD_LIBRARY_PATH on
Solaris) yet I still end up with the duplicate linker arguments.
I'm off to see if I can figure out how this is happening.
Kind regards
Amos
