[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53B021DD.2070100@langurwallah.org>
Date: Sun, 29 Jun 2014 19:55:33 +0530
From: Weldon Goree <weldon@...gurwallah.org>
To: musl@...ts.openwall.com
Subject: Re: Is there a "right" way to deal with error.h inclusions?
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.
Weldon
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.
