RPM Community Forums

Mailing List Message of <popt-devel>

Re: POPT's API has designed in memory leaks. What to do?

From: Danny Sung <danny@dannysung.com>
Date: Mon 07 Jun 2010 - 22:40:18 CEST
Message-ID: <4C0D5932.1060001@dannysung.com>

On 6/7/2010 11:29 AM, Jeff Johnson wrote:
>
> On Jun 7, 2010, at 2:00 PM, Danny Sung wrote:
>
>> I agree.  I have no problems with breaking binary&source compatibility especially if that change will make popt better/easier in the future. But a change in name seems necessary for app developers to make that choice.  eg. what happens if you're building mulitiple different software packages... both dynamically linking popt, but one uses 1.x and the other 2.x?  The header files would also need something like #include<popt2/popt2.h>  or something like that.  Can't say I particularly like it... but it does those issues somewhat cleanly.
>>
>
> I respectfully and strongly _DISAGREE_. The issue can be best be
> dealt with by using ELF symbol versioning (once I get that it place
> again in popt-1.17) where a single library can provide _BOTH_
> POPT 1.0 and POPT 2.0 functionality _TRANSPARENTLY_ (one the
> necessary pre-requsite of adding ELF symbol versioning is achieved).

Doesn't this only work if you're maintaining source compatibility? 
(whiihc is good, I just thought you said you weren't aiming for that).
Sorry, not trying to be difficult... just trying to understand.  Also 
does ELF symbol versioning work for both dynamically and statically 
linked apps?

> If I rename "popt" to "tdod" (or "popt2" that precludes even the attempt at
> doing better engineering using ELF symbol versioning. While I'm
> not averse to renaming, I've seen the bleary package churn from
> libxml ->  libxml2 and GNOME 1.0 ->  GNOME 2.0. No way Jose!

Yeah, I thought it was ugly too.  But it makes sense... in an ugly way.
Received on Mon Jun 7 22:40:43 2010
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.