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 neithe
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 intro
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
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 implementa
