This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFA: consolidate DWARF strings into libiberty

On Mon, Mar 19, 2012 at 9:09 AM, Doug Evans <> wrote:
> On Thu, Mar 15, 2012 at 12:02 PM, Tom Tromey <> wrote:
>>>>>>> "DJ" == DJ Delorie <> writes:
>> Tom> Finally, there is already stuff in libiberty not related to
>> Tom> portability. ?E.g., hashtab or the demangler.
>> DJ> Yeah, I know, hence my "Should I give up that premise?"
>> Yeah.
>> I am not sure there will ever be enough shared code to warrant a new
>> library, particularly because adding a new library is so expensive --
>> not just the configury stuff but also adding it to the link lines in the
>> Makefiles of all the tools that might need it.
>> I suppose if I had my wish list implemented here, it would be to remove
>> the portability stuff from libiberty in favor of gnulib, and keep
>> libiberty as a higher-level library.
> That won't really fix libiberty being an ever growing kitchen sink.
> How hard would it really be to make it easier to add new libraries?
> It's not like we're expecting 100.
> But given the pushback for even one new library, I think we're
> unnecessarily slowing ourselves down.


While I like using gnulib more, do we know it will necessarily always
solve portability problems in a timely manner?  I wouldn't mind
keeping libiberty as a fallback.

Plus, some of the complexity of libiberty is supporting all of
$build,$host,$target in one build.
The utilities I think you're thinking of adding (or at least the
utilities I've come across as wanting to add to a more useful
location) are just for the tools (i.e. $host).  Putting them in
libiberty doesn't "feel right".

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]