Mailing List Archive

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
-mike

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
> -mike

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 ?

Patrice

----
This message contains confidential information and may contain information that is legally privileged. If you have received this message by mistake, please immediately notify us and delete the original message. Thank you.

Ce message contient des informations confidentielles. S'il vous est parvenu par erreur, merci de bien vouloir nous en aviser par retour, de n'en faire aucun usage et de n'en garder aucune copie.
----

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.
-mike

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

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