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
signature.asc
Description: This is a digitally signed message part.
