On Sun, 30 Apr 2006, Daniel Stenberg wrote:

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

> > daniel writes:
>
> > > 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?

simply, i want the ability to be able to *completely* bypass any
*other* installed openssl stuff on this system that would normally be
found by accident.

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

i would have thought exactly the opposite -- that it's a *very* common
thing you'd need to be able to do. if i'm building a set of
cross-compiled components, i need the ability to configure and build
those components *precisely* against the other components that will
eventually be installed on that same system.

it would be a bad thing if, in the process of cross-compiling, the
build process started picking up pieces of the native stuff sprinkled
around the build system, perhaps getting the wrong version of stuff in
the process.

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

exactly. its purpose is to say, "i want you to use *that* openssl
tree over there, and ignore everything else openssl-related on this
host." my only quibble is that it's not refined enough to be able to
specify, independently, the lib location and the header file location,
but we've already agreed that that's a limitation that should be
patchable.

and, no, you can't solve it by doing an "install", even a bogus
install to get the right structure.

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

i'm not aware that there *is* any other kind of system. i'm trying to
cross-compile openssl and curl for PPC on a system that already *has*
openssl and curl built and installed for x86. in what way is that not
a "mixed system" by your definition? the fact that my build system
has openssl and curl already installed should *in no way* interfere
with my cross-compilation process.

rday
Received on 2006-04-30