On Sun, 30 Apr 2006, Robert P. J. Day wrote:

>> Aha. So you have a set already installed in the default search paths
>> you don't want found?
>
> um, yes. what's wrong with that? in fact, there are probably *two* sets --
> one is the native set on this install of FC5, the other is the set that's
> part of the ELDK toolchain. why is that an issue?

What are you really asking here?

> shouldn't i be able to bypass them?

Well, its not really a very common situation so it isn't something we work
around frequently. At least not to my knowledge.

> isn't that the whole point of "--with-ssl" in the first place?

Not really. IMO, --with-ssl's biggest point is to point out an install tree
that _is not_ the in the default search path for the linker and compiler.

>> It makes me wonder why you don't move them away so that the compiler
>> and linker don't find them, as you obviously don't want to use them.
>
> because moving them would undoubtedly break *other* things. i'm certainly
> not going to move my native install of openssl -- all *sorts* of things
> would go hideously wrong.

I would call mixing native and cross-compiled libs/headers a very weird system
setup. But that's just me.

> if no one else is interested, i'll take a look and see if i can do that.
> i'm assuming it wouldn't be overly difficult since it's just a logical
> extension of --with-ssl. (one would think that one possible solution would
> be that defining --with-ssl would simply define those other two to have the
> same value. but i'll poke around.)

I believe it is slightly harder than it might sound because of all the tiny
little quirks that have been added over the years to make the SSL builds work
all over.

But please give it a shot, there should be a bunch of guys around here who can
help out and who can review your patches!

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html