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