It is obvious that its modification time will change with each such file
builded.
This bug cause whole libelf to rebuild itself each second make run
(and relink that files on each first make run) in the loop.
When building libelf in the bootstrap stage this would include the tree
versions of, for example, sys/_types.h. This would work as long as the
tree's version of this file was close enough to the system's version of
the file. If, however, there was a change in the tree such that the location
of a typedef was moved this would cause problems. In this case the version
of sys/_types.h in the tree no longer defines __wchar_t and expects it to
to be defined in machine/_types.h, however we pick up machine/_types.h from
the system and find it is not defined there. The solution is to restrict the
parts of sys er include from the tree to those that are needed.
This fixes the recent Tinderbox failure.
Pointy Hat to: andrew
`_libelf_ar_open()` to a new compilation unit "libelf_ar_util.c"
to break the circular dependency between "elf_memory.o" and
"libelf_ar.o".
Obtained from: elftoolchain
MFC after: 1 month
favour of `elf_getshdrnum()`, `elf_getphdrnum()` and `elf_getshdrstrndx()`
respectively.
* Add new manual pages for `elf_getshdrstrndx()`, `elf_getphdrnum()` and
`elf_getshdrnum()`.
* Add a deprecation warning for `elf_getshstrndx()`, `elf_getphnum()` and
`elf_getshnum()`.
Obtained from: elftoolchain
MFC after: 1 month
Similar to libexec/, do the same with lib/. Make WARNS=6 the norm and
lower it when needed.
I'm setting WARNS?=0 for secure/. It seems secure/ includes the
Makefile.inc provided by lib/. I'm not going to touch that directory.
Most of the code there is contributed anyway.
members of the ELF Executable Header inside the library-private
`struct _Elf' descriptor and only update the underlying Elf{32,64}_Ehdr
structure on an elf_update(3) call. These fields of the Ehdr
structure are technically `out of bounds' for an application program
per the ELF(3) API, but we've seen applications that initialize
a new Ehdr structure using memcpy(), messing up the library's
invariants. [1]
Implement elf_getphnum() and handle ELF objects with more than
64K program header table entries.
Reported by: jb [1]
to determine which Elf Types are to be handled. Change the M4
templates to wrap an `#if __FreeBSD_version >= NNN'/`#endif' pair
around the generated code for each ELF data type, where `NNN' is
the OS version where the ELF type was added to the source tree.
This change allows cross-builds of old sources on newer FreeBSD
systems to work correctly.
Problem reported by: ru
