Fwd: Please backport a patch to branches/uClibc_0_9_30

[Kyle Sallee]

On Sun, May 10, 2009 at 2:38 PM, Christian MICHON
<christian.michon at gmail.com> wrote:
> On Sun, May 10, 2009 at 11:08 PM, Mike Frysinger <vapier at gentoo.org> wrote:
>> On Saturday 09 May 2009 20:37:28 Kyle Sallee wrote:
>>
>> please do not top post
>
> unfortunately the default when using gmail :(
>
>>
>>> Headers from linux kernel 2.6.29.2 can be used.
>>> At least I compiled uClibc using 2.6.29.1 kernel headers.
>>
>> the problem is that uClibc doesnt have a way in the source to say "only use
>> features available in linux-x.y.z and older".  instead, it'll use whatever ABI
>> the headers declare.  so if you want to use linux-2.6.17, you probably
>> shouldnt use linux-2.6.29+ if you want to be safe.
>> -mike
>
> could this explain his static linking failures on p7zip ? using the wrong API ?

Someone confused the other person's problems with mine.
That is probably my fault for top posting a reply.
I use a proper cross-compile tool chain.
I am more than certain ld links with uClibc's libc.a,
because I moved /usr/lib/libc.a from glibc to a different name.
I also had a wrapper on /usr/bin/ld to make certain it was not invoked.
Therefore, only my toolchain ld was invoked for linking.
So far the only aspects I know about the problem with compiling p7zip
statically linked with uClibc's libc.a is that -O3 creates a 7za
that immediately segfaults when run, and -Os works fine.
Naturally, I have to recompile uClibc and p7zip with an additional -g,
before I can run gdb on it and see what might be the problem.
Yet at the moment it is not a top priority since I can simply
avoid using -O3.  :)
Yet it does seem worth reporting on the uClibc list
since the error happens when statically linking with uClibc,
but can not be replicated when statically linking with glibc.

The other person's problem was that the busybox he compiled
linked with /lib/ld-linux.so.2 instead of /lib/ld-uClibc.so.0
He reported that he circumvented the problem by changing
the symbolic link /lib/ld-linux.so.2 to point to ld-uClibc-0.....so
Therefore, I quoted the relevant part in the gcc manual page
and suggested that the problem may be due to compiling
busybox without using a uClibc toolchain
Yes, entirely different problems.
Sorry for causing confusion while trying to be helpful.