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
<[email protected]> 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
