On Tue, 2015-03-31 at 17:14 +0200, Petr Machata wrote: > Mark Wielaard <[email protected]> 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 included before. 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 #included first. Cheers, Mark
