Provide elf.h to applications

[simonsouth]

ELF-based UNIX systems commonly provide a public header file, elf.h, that defines the various structures and constants used by the ELF file format. (GNU libc includes one, for instance.)

Haiku does not, though one can easily be assembled from the definitions in its private header files ​elf_common.h, ​elf32.h and ​elf64.h.

The first patch I'm attaching does exactly that, creating elf.h in headers/os/kernel (the most sensible location, it seems to me, from the ​default search paths) entirely from existing code. This includes Haiku's C++ extensions to the ELF structures but not the handful of definitions used only by itself internally.

This change allows UNIX applications that rely on the presence of elf.h, among them GNU Emacs, to build on Haiku without modification.

The second patch eliminates the duplication of code created by the first by refactoring Haiku itself to use the new, public elf.h header. Specifically, it

• Removes now-redundant code from elf_common.h and deletes elf32.h and elf64.h altogether.
• Renames elf_common.h to elf_private.h (following the pattern of existing, adjacent files, such as architecture_private.h and node_monitor_private.h) as it now contains only Haiku-internal definitions.
• Updates the files that included the original headers to build with the private and public ELF header files together, including minor updates to match the definitions in the public header file (removing the struct keyword, basically).

[simonsouth]

Provide elf.h to applications

[simonsouth]

Haiku: Build using public and private ELF header files

[Max-Might]

This is nice.

I needed elf.h when I tried to port some lib to Haiku. It was libunwind if I remember correctly. It may need other stuff too but this was the first error I hit. Thanks for the patches, will try again when I have the time (and someone merges this).

[pulkomandy]

There is a recipe for libunwind in haikuports, I think the recipe includes a minimal elf.h. But providing it from Haiku side is cleaner. cmake will also make use of it.

[korli]

There probably is a copyright problem if we remove Travis name, without checking which part he originated. It might easier to just ask him to agree on the change.

[simonsouth]

Good point. I'll write to him unless you intend to.

[korli]

Replying to simonsouth:

Good point. I'll write to him unless you intend to.

You can write to him, or contact him on IRC (nickname geist). If he can confirm in this ticket with a short comment, that would be cool.

[jessicah]

Applied in hrev49754.

Travis' copyright is still present in elf_private.h, so I'm not sure where the issue is. Public headers shouldn't list authors, and authorship can be tracked via commit history.

[jessicah]

FYI, Travis approved the changes to copyright via IRC.

[korli]

Fine. IIRC a part of the private header with Travis' copyright was then included in a public header without this same copyright, which then looks like a copyright removal.