|
Message-ID: <20140629154357.GA179@brightrain.aerifal.cx> 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.