vapier at gentoo
Jan 4, 2011, 11:03 PM
Post #6 of 6
On Tuesday, January 04, 2011 17:12:58 Patrice Tisserand wrote:
Re: e2fsprogs checking for blkid_get_cache in -lblkid... no
[In reply to]
> On 01/04/2011 07:59 PM, Mike Frysinger wrote:
> > On Tuesday, January 04, 2011 04:02:59 Patrice Tisserand wrote:
> >> Does adding -L /tmp/target_root/lib -L /tmp/target_root/usr/lib
> >> -Wl,-rpath-link,/tmp/target_root/lib
> >> -Wl,-rpath-link,/tmp/target_root/usr/lib to LDFLAGS could not be an
> >> alternative ?
> > no. that's broken by design.
> Thanks for your answer, I have found the following sentence in gentoo
> embedded handbook:
> """The common convention is to use your /usr/CTARGET/ tree as your
> sysroot as the include/library directories in this tree are already
> encoded into the gcc cross-compiler for searching. You could use another
> directory and then add custom -I/-L paths to your CPPFLAGS/LDFLAGS, but
> this has historically proven to be problematic. Yes, it works most of
> the time, but the corner cases are why this method is discouraged. In
> the embedded handbook, we'll assume you're using the sysroot as your
> development ROOT.
> Do you know where I can find references about these corner cases ?
perhaps ive cited examples on this list in the past, but i dont recall. i'll
just refer to Bug 347489 and mention the same issue with like
curses/bash/screen off the top of my head.
> Also how can I handle creating 2 different target rootfs with different
> libraries versions but using the same cross-compilation toolchain?
> Do I need to duplicate environment or is there some tips ?
i dont know why you'd do this, but the cleanest approach today would be to
create a new cross-compiler toolchain with a slightly different vendor so you
get unique paths. i imagine it'd be possible to also take the default gcc
specs, tweak the sysroot arg in it, and export the GCC_SPECS env var, but it
could get messy as you'd have to remember what you have your env set to.