Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140629140923.GY179@brightrain.aerifal.cx>
Date: Sun, 29 Jun 2014 10:09:23 -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 03:47:46PM +0200, Luca Barbato wrote:
> On 29/06/14 14:34, Weldon Goree wrote:
> > Hi all,
> > 
> > I've been dealing with unconditional inclusions of error.h in a pretty
> > ad-hoc way in building different things against musl. Does anybody know
> > of an autohell macro that could be reliably wrapped around error.h
> > inclusions and its defined functions? (Alternately, any non-auto* based
> > solution that's worked for people?)
> 
> Do you need to check for presence or presence of a symbol in the header?

Unlikely; probably the existence or nonexistence of the header, for
which there's a completely standard approach. But I think he was also
asking for a way to do a fallback when they're absent.

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.

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.