On Sun, 30 Apr 2006, Daniel Stenberg wrote:

> On Sun, 30 Apr 2006, Robert P. J. Day wrote:
>
> > it does *not*, however, guarantee that *those* are the directories
> > from which the header files and/or libraries will be obtained if
> > those same files are found earlier on the search paths. (which
> > is, in fact, exactly what happens if you're trying to
> > cross-compile with ELDK 3.1.1.)
>
> 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?
shouldn't i be able to bypass them? isn't that the whole point of
"--with-ssl" in the first place?

> 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.

> > what's missing that would solve this problem would be the
> > equlvalent of:
> >
> > --with-ssl-libs=
> > --with-ssl-headers=
> >
> > which would *force* the selection of those files.
>
> I agree, if we'd had those options all your problems would've been
> solved instantly. I wouldn't object to a patch adding them!

ah, now we have agreement. 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.)

rday
Received on 2006-04-30