Mailing List Archive: Gentoo: Embedded

e2fsprogs checking for blkid_get_cache in -lblkid... no

Index | Next | Previous | View Threaded

lavi.kfir at gmail

Jan 3, 2011, 2:19 AM

Post #1 of 6 (685 views)
Permalink

e2fsprogs checking for blkid_get_cache in -lblkid... no

Hi,
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?

Regards,
Kfir

vapier at gentoo

Jan 3, 2011, 10:41 AM

Post #2 of 6 (682 views)
Permalink

Re: e2fsprogs checking for blkid_get_cache in -lblkid... no [In reply to]

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

Attachments:

signature.asc (0.82 KB)

ptisserand at wyplay

Jan 4, 2011, 1:02 AM

Post #3 of 6 (629 views)
Permalink

Re: e2fsprogs checking for blkid_get_cache in -lblkid... no [In reply to]

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

vapier at gentoo

Jan 4, 2011, 10:59 AM

Post #4 of 6 (626 views)
Permalink

Re: e2fsprogs checking for blkid_get_cache in -lblkid... no [In reply to]

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

Attachments:

signature.asc (0.82 KB)

ptisserand at wyplay

Jan 4, 2011, 2:12 PM

Post #5 of 6 (625 views)
Permalink

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

vapier at gentoo

Jan 4, 2011, 11:03 PM

Post #6 of 6 (630 views)
Permalink

Re: e2fsprogs checking for blkid_get_cache in -lblkid... no [In reply to]

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

Attachments:

signature.asc (0.82 KB)

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads