[Scratchbox-users] SB2 - mixing Host and Target directories

[Lauri Leukkunen]

On 11/12/07 17:49 +0100, Harald Radke wrote:
> > It seems sb2 has gotten a little slow ;)
> > I guess the busybox buildsystem is hitting the path mapping code pretty
> > hard. Will have to look at this more later.
> well, I actually guess that getting things like busybox to work inside sb2 
> isn't that important since it is designed to cross compile....so I think I 
> will go with the "natural" way of building BB  and leave sb2 to things that 
> are ment to be build on the target system

That's the right way to go about, anything that supports cross-compilation
natively, should be built that way. I think sb2 is pretty good at solving the
regular autotools package, anything totally exotic is likely to not work and
I don't want to take the design decisions to make sb2 bulletproof, 

SB1 did that and it ended up being a gigantic project which still failed to 
solve 100% of the problem, requiring modifications to the build system or
custom hacks in SB1 to work around things.

> > Does your gcc support --sysroot switch? It's needed for sb2.
> > Anyway, you could run "sb2 -d gcc -o test main.c" and send the resulting
> > ~/sb2_mapping_*.log to me so I can take a closer look at why it isn't
> > finding the headers.
> I actually disables sysroot switch since I suspect it to be responsible for 
> the problems in the beginning when crt* files weren't found by the toolchain
> 
> I will recompile the toolchain with it and see what happens before sending u a 
> big unecessary logfile (:

I don't mean if you built your toolchain with --sysroot switch, just that if
you run cross-compiling-gcc --help, do you see --sysroot as being one of the
supported options? SB2 uses that to tell it where the filesystem root is,
regardless of how the toolchain was built.

> PS: I suggest to set PKG_CONFIG_PATH env var inside SB2 to 
> SBOX_TARGET_ROOT/usr/lib/pkgconfig or similiar, though I don't have to admit 
> I don't know the consequences in total I guess this would lead to a better 
> and more correct support for this tool..

Do you witness a problem with it? This should be handled by the path mapping
engine.

/lauri