Mailing List Archive

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