On Tue, 2015-03-31 at 17:14 +0200, Petr Machata wrote:
Mark Wielaard <mjw(a)redhat.com> writes:
> The issue really is that a user could have their own #include <elf.h>
> already. So we cannot just change libelf.h to #include <elfutils/elf.h>.
> I am not sure how to nicely make known-elf.h work if we make it an
> installed header given we don't fully control elf.h. Maybe we can just
> make known-elf.h include the correct elf.h itself. And tell users to
> never use #include <elf.h> when using libelf.h and/or known-elf.h?
Does it make sense to base the contents of known-elf.h on the installed
No. We don't control that file, so a user could upgrade (or downgrade)
it independently from known-elf.h.
> But known-elf.h could still be useful even if we only use it as
> header. So I would still like to see it.
That would make the whole deal much less useful.
Indeed. But I think I was panicking too much about theoretical
situations. I now think it isn't an issue to install our own
elfutils/elf.h file that matches elfutils/known-elf.h.
The only requirement we have to put onto the user is that they #include
elfutils/elf.h and elfutils/known-elf.h before including elf.h, gelf.h
or libelf.h. And we don't have to change libelf.h or gelf.h. We can even
add an #error check #ifdef _ELF_H to make sure elf.h hasn't been
The reason this works is because this is only for new code and
elfutils/elf.h always will define at least the minimum types and
constants from elf.h. So re-including the system elf.h should just be
fine, it will just see _ELF_H already be defined, so won't redefine
anything. So existing code doesn't need to change anything to start
using elfutils/known-elf.h as long as it (and elfutils/elf.h) is