Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Embedded

Problems compiling sandbox with uclibc

 

 

Gentoo embedded RSS feed   Index | Next | Previous | View Threaded


lists at wildgooses

Jun 28, 2009, 8:04 AM

Post #1 of 8 (1440 views)
Permalink
Problems compiling sandbox with uclibc

Hi, I'm unable to compile sandbox with uclibc on x86. The error occurs
in the configure stage as follows:

...snip...
checking CFLAGS for maximum warnings... no, unknown
checking whether C compiler accepts -fdata-sections... no
checking whether C compiler accepts -ffunction-sections... no
checking whether the linker accepts -Wl,--as-needed... no
checking whether the linker accepts -Wl,--gc-sections... no
checking whether the linker accepts -Wl,--version-script,conftest.map... no
checking whether the linker accepts -Wl,-M,conftest.map... no
configure: error: unable to find a linker flag for versioning

!!! Please attach the following file when seeking support:
!!! /var/tmp/portage/sys-apps/sandbox-1.6-r2/work/build-default/config.log
*
* ERROR: sys-apps/sandbox-1.6-r2 failed.


Checking the config.log it appears to be because of a broken definition
which is split over two lines

#define LIBC_VERSION "libc.so.0
| ld-uClibc.so.0"


The test causing this is:

LIBC_VERSION=$(
$READELF -d libctest | \
$EGREP NEEDED.*libc\\.so | \
$AWK '{print $NF}' | sed -e 's:\[::' -e 's:\]::'
)


and readelf gives me:

0x00000001 (NEEDED) Shared library: [libc.so.0]
0x00000001 (NEEDED) Shared library: [ld-uClibc.so.0]

Which in turn leads to the multiple line output


However, I can't actually see where LIBC_VERSION is even used? Is there
someone here who understands what is happening and can recommend the
best fix? (Remove the whole test?)

How come no one else is seeing this? What does readelf give for others
using uclibc?

Ed W


lists at wildgooses

Jun 28, 2009, 11:52 AM

Post #2 of 8 (1387 views)
Permalink
Re: Problems compiling sandbox with uclibc [In reply to]

Ed W wrote:
> Hi, I'm unable to compile sandbox with uclibc on x86. The error
> occurs in the configure stage as follows:
>
> ...snip...
> checking CFLAGS for maximum warnings... no, unknown
> checking whether C compiler accepts -fdata-sections... no
> checking whether C compiler accepts -ffunction-sections... no
> checking whether the linker accepts -Wl,--as-needed... no
> checking whether the linker accepts -Wl,--gc-sections... no
> checking whether the linker accepts
> -Wl,--version-script,conftest.map... no
> checking whether the linker accepts -Wl,-M,conftest.map... no
> configure: error: unable to find a linker flag for versioning
>
> !!! Please attach the following file when seeking support:
> !!!
> /var/tmp/portage/sys-apps/sandbox-1.6-r2/work/build-default/config.log
> *
> * ERROR: sys-apps/sandbox-1.6-r2 failed.
>
>
> Checking the config.log it appears to be because of a broken
> definition which is split over two lines
>
> #define LIBC_VERSION "libc.so.0
> | ld-uClibc.so.0"
>
>
> The test causing this is:
>
> LIBC_VERSION=$(
> $READELF -d libctest | \
> $EGREP NEEDED.*libc\\.so | \
> $AWK '{print $NF}' | sed -e 's:\[::' -e 's:\]::'
> )
>
>
> and readelf gives me:
>
> 0x00000001 (NEEDED) Shared library: [libc.so.0]
> 0x00000001 (NEEDED) Shared library: [ld-uClibc.so.0]
>
> Which in turn leads to the multiple line output
>
>
> However, I can't actually see where LIBC_VERSION is even used? Is
> there someone here who understands what is happening and can recommend
> the best fix? (Remove the whole test?)
>
> How come no one else is seeing this? What does readelf give for
> others using uclibc?
>
> Ed W
>


Does this patch feel right:

--- sandbox-1.6/configure.old 2009-06-28 18:28:04 +0000
+++ sandbox-1.6/configure 2009-06-28 18:29:22 +0000
@@ -15911,6 +15911,7 @@
LIBC_VERSION=$(
$READELF -d libctest | \
$EGREP NEEDED.*libc\\.so | \
+ $EGREP -v \\[.ld- | \
$AWK '{print $NF}' | sed -e 's:\[::' -e 's:\]::'
)
rm -f libctest*


http://bugs.gentoo.org/show_bug.cgi?id=275725


lists at wildgooses

Jun 29, 2009, 3:40 AM

Post #3 of 8 (1387 views)
Permalink
Re: Problems compiling sandbox with uclibc [In reply to]

Ed W wrote:
> However, I can't actually see where LIBC_VERSION is even used? Is
> there someone here who understands what is happening and can recommend
> the best fix? (Remove the whole test?)
>
> How come no one else is seeing this? What does readelf give for
> others using uclibc?
>
> Ed W
>

Hmm, now I see it's used in libsandbox/wrappers.c

So in order to fix this, which of the two options should *really* be
used? Is it enough to change the test to exclude one? Is my system
unusual in listing two similarly named files?

Thanks

Ed W


lists at wildgooses

Jun 30, 2009, 8:30 AM

Post #4 of 8 (1389 views)
Permalink
Re: Problems compiling sandbox with uclibc [In reply to]

> and readelf gives me:
>
> 0x00000001 (NEEDED) Shared library: [libc.so.0]
> 0x00000001 (NEEDED) Shared library: [ld-uClibc.so.0]
>
> Which in turn leads to the multiple line output

Is no one else seeing this with a uclibc based system? Why am I special...?

Ed W


solar at gentoo

Jun 30, 2009, 8:59 AM

Post #5 of 8 (1370 views)
Permalink
Re: Problems compiling sandbox with uclibc [In reply to]

On Tue, 2009-06-30 at 16:30 +0100, Ed W wrote:
> > and readelf gives me:
> >
> > 0x00000001 (NEEDED) Shared library: [libc.so.0]
> > 0x00000001 (NEEDED) Shared library: [ld-uClibc.so.0]
> >
> > Which in turn leads to the multiple line output
>
> Is no one else seeing this with a uclibc based system? Why am I special...?

This is more suited in https://bugs.gentoo.org


lists at wildgooses

Jun 30, 2009, 9:15 AM

Post #6 of 8 (1375 views)
Permalink
Re: Problems compiling sandbox with uclibc [In reply to]

Ned Ludd wrote:
> On Tue, 2009-06-30 at 16:30 +0100, Ed W wrote:
>
>>> and readelf gives me:
>>>
>>> 0x00000001 (NEEDED) Shared library: [libc.so.0]
>>> 0x00000001 (NEEDED) Shared library: [ld-uClibc.so.0]
>>>
>>> Which in turn leads to the multiple line output
>>>
>> Is no one else seeing this with a uclibc based system? Why am I special...?
>>
>
> This is more suited in https://bugs.gentoo.org
>
>
>

As per previous email, see:
https://bugs.gentoo.org/show_bug.cgi?id=275725

I have submitted a patch there which seems safe, but not having many
uclibc systems to compare I just wanted to get a sense of whether my
toolchain is building things incorrectly versus actually needing this patch

Perhaps you could kindly run "readelf -d" on some binary in your uclibc
system and tell me if you have the "ld-uClibc.so" listed? If so then I
think the patch is sensible and required (and likely a safe commit)


Cheers

Ed W


solar at gentoo

Jun 30, 2009, 10:17 AM

Post #7 of 8 (1376 views)
Permalink
Re: Problems compiling sandbox with uclibc [In reply to]

On Tue, 2009-06-30 at 17:15 +0100, Ed W wrote:
> Ned Ludd wrote:
> > On Tue, 2009-06-30 at 16:30 +0100, Ed W wrote:
> >
> > > > and readelf gives me:
> > > >
> > > > 0x00000001 (NEEDED) Shared library: [libc.so.0]
> > > > 0x00000001 (NEEDED) Shared library: [ld-uClibc.so.0]
> > > >
> > > > Which in turn leads to the multiple line output
> > > >
> > > Is no one else seeing this with a uclibc based system? Why am I special...?
> > >
> >
> > This is more suited in https://bugs.gentoo.org
> >
> >
> >
>
> As per previous email, see:
> https://bugs.gentoo.org/show_bug.cgi?id=275725
>
> I have submitted a patch there which seems safe, but not having many
> uclibc systems to compare I just wanted to get a sense of whether my
> toolchain is building things incorrectly versus actually needing this
> patch
>
> Perhaps you could kindly run "readelf -d" on some binary in your
> uclibc system and tell me if you have the "ld-uClibc.so" listed? If
> so then I think the patch is sensible and required (and likely a safe
> commit)

uClibc bin # readelf -d /bin/ls | grep libc
0x00000001 (NEEDED) Shared library: [libc.so.0]

uClibc bin # qlist -eo sandbox | scanelf -f - -nB
ET_DYN libc.so.0,libdl.so.0 /usr/lib/libsandbox.so
ET_DYN libc.so.0 /usr/bin/sandbox
--

uClibc bin # qlist -ICv sandbox gcc binutils uclibc -e
sys-apps/sandbox-1.9
sys-devel/binutils-2.19.1-r1
sys-devel/gcc-3.4.6-r2
sys-devel/gcc-4.2.4-r1
sys-devel/gcc-4.3.3-r2
sys-libs/uclibc-0.9.30.1-r1


lists at wildgooses

Jun 30, 2009, 10:57 AM

Post #8 of 8 (1372 views)
Permalink
Re: Problems compiling sandbox with uclibc [In reply to]

Ned Ludd wrote:
> On Tue, 2009-06-30 at 17:15 +0100, Ed W wrote:
>
>> Ned Ludd wrote:
>>
>>> On Tue, 2009-06-30 at 16:30 +0100, Ed W wrote:
>>>
>>>
>>>>> and readelf gives me:
>>>>>
>>>>> 0x00000001 (NEEDED) Shared library: [libc.so.0]
>>>>> 0x00000001 (NEEDED) Shared library: [ld-uClibc.so.0]
>>>>>
>>>>> Which in turn leads to the multiple line output
>>>>>
>>>>>
>>>> Is no one else seeing this with a uclibc based system? Why am I special...?
>>>>
>>>>
>>> This is more suited in https://bugs.gentoo.org
>>>
>>>
>>>
>>>
>> As per previous email, see:
>> https://bugs.gentoo.org/show_bug.cgi?id=275725
>>
>> I have submitted a patch there which seems safe, but not having many
>> uclibc systems to compare I just wanted to get a sense of whether my
>> toolchain is building things incorrectly versus actually needing this
>> patch
>>
>> Perhaps you could kindly run "readelf -d" on some binary in your
>> uclibc system and tell me if you have the "ld-uClibc.so" listed? If
>> so then I think the patch is sensible and required (and likely a safe
>> commit)
>>
>
> uClibc bin # readelf -d /bin/ls | grep libc
> 0x00000001 (NEEDED) Shared library: [libc.so.0]
>
> uClibc bin # qlist -eo sandbox | scanelf -f - -nB
> ET_DYN libc.so.0,libdl.so.0 /usr/lib/libsandbox.so
> ET_DYN libc.so.0 /usr/bin/sandbox
> --
>
> uClibc bin # qlist -ICv sandbox gcc binutils uclibc -e
> sys-apps/sandbox-1.9
> sys-devel/binutils-2.19.1-r1
> sys-devel/gcc-3.4.6-r2
> sys-devel/gcc-4.2.4-r1
> sys-devel/gcc-4.3.3-r2
> sys-libs/uclibc-0.9.30.1-r1
>
>
>
>

Hmm, so it looks like something in my setup

Can you speculate why I might be getting this extra lib linked??

Thanks

Ed W

Gentoo embedded RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.