Shibboleth Developers

["Cantor, Scott E." <>]

On 5/20/11 1:24 PM, "Tom Poage" 
<>
 wrote:
>One of thing I'd considered toying with for platforms needing libcurl
>linked against OpenSSL is to rename the library itself to something like
>libcurl-openssl.so.3.0.0 so it doesn't conflict with that supplied by
>the OS. Unfortunately, one would then also have to link shibd against
>this library.

That's how Debian works. The main problem is that it's hard; I looked at
their patches, and I was not comfortable maintaining them. I might decide
I'm willing if I have more time to spend on it, but doing what I did was
much less work.

The other problem is that you still have a conflict between
libcurl-devel's of different flavors, generally. It's quite confusing in
practice.

>Flip side, a curl library with a different name might be more generally
>useful to other (TBD) code needing the same feature set as shibd.

I think the PRELOAD option actually is more viable in that respect,
because you have to start playing games with configure scripts to use a
different libname, and projects don't really want to do that.

>The only reason I was thinking of this route was a very old assertion
>(Gene Spafford?) that LD_LIBRARY_PATH and kin were insecure. I don't
>know if LD_PRELOAD remedies any of these old concerns.

As a Windows person, I generally avoid the shared library wars that go on
in the Unix community.

>FWIW, as recently as RHEL 5 (not tested with RHEL 6) local RPM builds
>were defaulting to /usr/local. Some of this may have had more to do with
>my peculiar use of cpan2rpm etc. than OS configuration.

I'm not sure what you mean by "local" builds.

It's true that autoconf defaults to /usr/local as a prefix, generally. But
RPM by default overrides all that via macros in the OS.

-- Scott