Re: [gentoo-embedded] e2fsprogs checking for blkid_get_cache in -lblkid... no

[Mike Frysinger]

On Tuesday, January 04, 2011 17:12:58 Patrice Tisserand wrote:
> 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.
-mike