On 04/25/15 05:41, Mark Wielaard wrote:
On Fri, Apr 24, 2015 at 07:13:04PM +0300, Max Filippov wrote:
> On Fri, Apr 24, 2015 at 2:49 PM, Anthony G. Basile
> <basile(a)opensource.dyc.edu> wrote:
>> On 04/23/15 18:24, Max Filippov wrote:
>>> A lot of tests failed because elfutils were built with --disable-progs
>>> (otherwise the build fails), and some test binaries failed to build
>>> because they call functions not available in uClibc.
>>
>> You might also want to take a look a [1]. I had to produce a series of
>
> Wow, I didn't know that gentoo can work with uClibc, that's great.
> I'll look at these patches.
If you could work together and see which patches seem reasonable to
submit upstream that would be appreciated. I cannot guarantee they
will all accepted if they make the code really complicated/broken.
The patches need some configure.ac love to test for the availability of
various features like mtrace() and add the appropriate #ifdef's. I
don't think they'll be overly complicated, I just didn't polish and push
them upstream because (in those days) I anticipated resistance. I'll
have some time in about a week and can get something ready.
And elfutils really is designed to make use of a full featured libc
like glibc. So if at all possible I would really recommend not using
something like uclibc. But we should do a reasonable attempt to make
sure the fork/difference isn't too big.
I get the drawback of not having symbol versioning, but uclibc was never
really designed with upgrades in mind. Nonetheless, I wouldn't minimize
uclibc's usefulness. I maintain gentoo on it for many arches [1] and,
for fun, I even build a fully featured desktop system to hit as many
libc level bugs as possible to expand uclibc's robustness/usefulness [2].
Ref.
[1]
https://wiki.gentoo.org/wiki/Project:Hardened_uClibc
[2]
https://wiki.gentoo.org/wiki/Project:Hardened_uClibc/Lilblue
--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197