This is the mail archive of the
mailing list for the elfutils project.
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Wed, 01 Apr 2015 16:30:50 +0200
- Subject: Re: known-elf.awk/known-elf.h
On Tue, 2015-03-31 at 17:14 +0200, Petr Machata wrote:
> Mark Wielaard <email@example.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
> elf.h then?
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 internal
> > 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