On 01/04/2011 07:59 PM, Mike Frysinger wrote:
On Tuesday, January 04, 2011 04:02:59 Patrice Tisserand wrote:
Mike Frysinger wrote:
On Monday, January 03, 2011 05:19:58 Kfir Lavi wrote:
when I try to cross compile sys-fs/e2fsprogs I get this error:
checking for blkid_get_cache in -lblkid... no
copying the uuid and blkid files to the cross environment solve the
problem and the package compiles.
cp /tmp/target_root/usr/lib/libuuid.*
/usr/i686-gentoo-linux-gnu/usr/lib/ cp
/tmp/target_root/usr/lib/libblkid.* /usr/i686-gentoo-linux-gnu/usr/lib/
cp /tmp/target_root/lib/libuuid.so.1* /usr/i686-gentoo-linux-gnu/lib/
cp /tmp/target_root/lib/libblkid.so.1* /usr/i686-gentoo-linux-gnu/lib/
How can this problem be solved permanently?
you should be emerging library packages into your SYSROOT (/usr/$CTARGET)
before building/installing packages into your ROOT
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 ?
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 ?
Regards,
Patrice
