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 <m...@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 <abdul...@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 <abdul...@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 >
