DLL conflict between SP and EMC Networker

[Cantor, Scott]

On 10/17/12 6:52 PM, "Elliot Kendall" <elliot.kendall at ucsf.edu> wrote:

>The hardest part of diagnosing this was preventing the install from
>getting rolled back.

I think we're still debating whether to leave this in or not. Right now
the installer won't finish/commit unless shibd starts up, which means it's
hard to address these kinds of cases. Since it's easier to diagnose
problems once it's installed, but won't start up, it may be better to let
it install.

>I don't think this particular problem has been posted about before, or
>at least I couldn't find it.

It used to happen all the time with openssl libraries. I don't think
anything has ever stuck libcurl in the path before.

>So I'm posting here partially to make the problem easy to find on
>Google and partially to get advice from any Windows gurus in the
>audience. What's the preferred fix for this kind of problem?

In general there isn't one. You could I suppose try moving libcurl.dll to
the shibd.exe directory and see if that loads. None of the web server
modules that really need things to be in the path are linked to it. But
that's not really a maintainable option, since that isn't where the file
is expected to live.

> All of the
>solutions in the DLL Hell Wikipedia article
>(http://en.wikipedia.org/wiki/DLL_Hell#Solutions) sound like they have
>to be applied in the application itself or at compile/link time. Should
>the Windows SP build be modified to take advantage of one or another?

None of the solutions that exist are very practical. The side by side
cache was the best, but MS essentially deprecated it, and it's a large
amount of work to use it and too late to consider at this point.

Renaming libcurl is essentially the only fix I know of. I would have to
consider whether I'm willing to take on that work. It's not a simple
change.

-- Scott