This is the mail archive of the
mailing list for the elfutils project.
Re: Versioned symbols in elfutils and uClibc
- From: Anthony G. Basile <basile at opensource dot dyc dot edu>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Sat, 25 Apr 2015 09:29:14 -0400
- Subject: Re: Versioned symbols in elfutils and uClibc
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
>> <firstname.lastname@example.org> 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 . 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  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 .
Anthony G. Basile, Ph. D.
Chair of Information Technology
Buffalo, NY 14201