On 5/22/2013 5:01 PM, Chris Ross wrote:
From mine:
libssl.so.10 => /usr/lib64/libssl.so.10 (0x00007f08f8eb2000)
I think that last number is simply a memory address, so it could be located
at a variety of different places depending on how squid was linked. Using
different options (such as, I'm not using kerberos) would affect that.
The important thing is the major version of the library for ABI
compatibility. We're all the same on that, they're all just variants of 1.0.0.
And, the issue in question isn't the library anyway. Linking isn't a problem,
it's compilation. The headers are what would need to change, or perhaps the
compiler or compilation options.
I also got a report back from my systems team that --enable-ssl works fine
on our systems, but --enable-ssl-crtd causes the compilation failure I'm
seeing. You used both of those, Eliezer?
- Chris
Hey Chris,
Now I remembered in a more detailed way that the reason was the crtd and
no ssl which is another thing.
I didn't used the crtd since there is a bug and also since most users
don't really need it.
OK so we have the same library and it's not corrupted but now we know
for 100% once and for all the source of the problem which os the crtd
and not enable-ssl.
since this bug was found I encouraged people to use self-compiled
openssl libs and headers.
I am sorry for redhat team but they seems to not want an upgrade because
last time it cost them too much pain in many places.
Will be it be hard for you to use a custom made ssl to build squid
specificly??
if this is the main issue and we can make it work in a more RPM way such
as using a good SPEC file to develop New openSSL I will be more then
happy to host it in order to spare a lot of pain from many people.
are you up for some of the task?
Eliezer
