[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 29 Jun 2014 11:43:57 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Is there a "right" way to deal with error.h inclusions?
On Sun, Jun 29, 2014 at 07:55:33PM +0530, Weldon Goree wrote:
> On 06/29/2014 07:39 PM, Rich Felker wrote:
> > Since the issue has come up several times, I'd like it if someone
> > could explain what all is involved in implementing these functions and
> > whether they would be candidates for addition to musl.
> >
> > Of course the best (most portable and easiest at build-time) solution
> > is simply not to use these functions, or if you're adapting legacy
> > code that already uses them, simply including an implementation in
> > your source tree and using it rather than the libc version.
>
> Personally, as a sysadmin rather than programmer, I'm trying to build
> software others have written with the assumption that GNU's error.h and
> its defined functions exist (procps-ng was the most recent one, but as
> you mentioned this affects several pieces of software).
>
> The ad-hoc bit I mentioned was that I'm usually doing exactly what you
> mentioned first: more or less (generally, less or even stub)
> implementing the functions that get called (horrifically, often just in
> a new <error.h> -- I know, I know...). I should probably just combine
> these into an error-compat library, but I was hoping somebody had
> already invented that wheel.
Yes, I know that's a pain. Again, I'm open to considering adding
compatible functions to musl, but first I need someone with an
interest in it to do the research on what's involved.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
