public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Saleem Abdulrasool <abdulras@google.com>
To: Mark Wielaard <mark@klomp.org>
Cc: elfutils-devel@sourceware.org
Subject: Re: [PATCH v2] handle libc implemntations which do not provide `error.h`
Date: Fri, 27 Aug 2021 08:44:30 -0700	[thread overview]
Message-ID: <CAO8XFHvsKL1eAd8KLdTT+R12Kn=EvzoPTCuKpKsuu4nMo1ys4g@mail.gmail.com> (raw)
In-Reply-To: <ed5a58858c145d214003577809c42e4c241b879d.camel@klomp.org>

We have two choices:
- revert and use the updated patch I already sent
- I can do a follow up change to migrate the code

I don't particularly have a strong opinion on which approach we take, since
the commit has already been done.  Since glibc systems are completely
untouched by the changes neither path should cause problems for bisection
in the future for previously supported systems.  I'd go with whatever is
most commonly done in this project.

On Fri, Aug 27, 2021 at 8:39 AM Mark Wielaard <mark@klomp.org> wrote:

> Hi Saleem,
>
> On Fri, 2021-08-27 at 08:24 -0700, Saleem Abdulrasool via Elfutils-devel
> wrote:
> > I think that this is not exactly ideal, as it will introduce a local
> > error_message_count in each translation unit, rather than giving it
> > vague linkage as I had hoped.  I think it may be better to introduce a
> new
> > source file here.  I can move the implementation around though.
> >
> > A second issue is that playing with this further, it doesn't fully
> resolve
> > the PR as this only fixes it for libelf (which I realized only recently).
>
> Oops. Our messages crossed and I just pushed:
>
> commit 76c84c137a82a7cacbc69b1696052491b3bb81cb
> Author: Saleem Abdulrasool <abdulras@google.com>
> Date:   Fri Aug 20 20:28:23 2021 +0000
>
>     handle libc implementations which do not provide `error.h`
>
>     Introduce a configure time check for the presence of `error.h`.  In the
>     case that `error.h` is not available, we can fall back to `err.h`.
>     Although `err.h` is not a C standard header (it is a BSD extension),
>     many libc implementations provide.  If there are targets which do not
>     provide an implementation of `err.h`, it would be possible to further
>     extend the implementation to be more portable.
>
>     This resolves bug #21008.
>
>     Signed-off-by: Saleem Abdulrasool <abdulras@google.com>
>
> It passes all local tests and it is currently going through the buildbot:
> https://builder.wildebeest.org/buildbot/#/changes/2530
> But of course all those systems use normal glibc.
>
> Should I revert the commit?
>
> Thanks,
>
> Mark
>

      reply	other threads:[~2021-08-27 15:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-20 20:28 Saleem Abdulrasool
2021-08-27 15:24 ` Saleem Abdulrasool
2021-08-27 15:39   ` Mark Wielaard
2021-08-27 15:44     ` Saleem Abdulrasool [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAO8XFHvsKL1eAd8KLdTT+R12Kn=EvzoPTCuKpKsuu4nMo1ys4g@mail.gmail.com' \
    --to=abdulras@google.com \
    --cc=elfutils-devel@sourceware.org \
    --cc=mark@klomp.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).