[DynInst_API:] dyninst 10.0 doesn't build with old glibc-headers and elf.h

["Mark W. Krentel" <krentel@xxxxxxxx>]

I've been working on building Dyninst 10.0 on Blue Gene with RedHat
6.x and old glibc-headers and I ran into the following problem.

The build dies in Object-elf.C with undefined symbol EM_AARCH64.
You've seen this problem before.  Elf_X.C and dwarfHandle.C have
code to work around an old elf.h with:

#if !defined(EM_AARCH64)
#define EM_AARCH64 183
#endif

This is now in a third file, Object-elf.C without the workaround. But
even if you added the above fix, there are still several more aarch64
symbols that remain undefined.  emitElfStatic.C uses:

R_AARCH64_RELATIVE
R_AARCH64_JUMP_SLOT
R_AARCH64_GLOB_DAT

I've fixed this in spack (once my PR is merged into develop) by having
elfutils install its copy of elf.h into the include dir.

Outside of spack, you could workaround this by adding '#if !defined(...)'
for all of the missing symbols.  (If you want to do this, it would make
sense to put them all in one file and #include that file.)

At this point, there are enough symbols that you may as well just
carry around your own version of elf.h.  (Which basically means that
every elfutils app has to keep its own elf.h, yuck.)  For this reason,
I actually recommend not doing this.

You could just do nothing.  The problem only happens with dyninst >=
10.0 and old glibc-header from RH <= 6.x.  Just put a note in the docs
that if you build a new dyninst on an old system and if the build
fails this way, then go into the elfutils source directory and copy
elf.h to the include dir.

Btw, does dyninst have code to build elfutils itself?  If you do,
then it would make sense to copy elf.h as part of the build.

Anyway, what I suggest that you do is complain to elfutils that they
should always install elf.h as part of their normal build.  One of the
main points of installing packages like this is access to newer
versions of files, in this case, elf.h.  Also, elfutils is building 
libelf.so
with one elf.h and you're building dyninst with a different elf.h,
which can't be correct.

Ben, this is the problem that I was telling you about at Scalable
Tools.  But now I have a concrete example where it matters.

--Mark