Re: elf.h: define SHT_SYMTAB_SHNDX

My original diff contained just SHT_SYMTAB_SHNDX addition. Martin comes with more opulent version which I just commented. Sure, I take the mistake of not mentioning that SHT_SYMTAB_SHNDX missing in OpenBSD affects GHC HEAD compilation on myself. On Sun, 21 Jan 2018 12:52:58 -0700 "Theo de

Re: elf.h: define SHT_SYMTAB_SHNDX

Then you should propose that, instead of adding 10 other unrelated things to the diff. > ping. The addition of SHT_SYMTAB_SHNDX is not just estetic improvement but > fixes GHC HEAD build failure on OpenBSD 6.2-current. Hence pinging. > > Thanks! > Karel > > On Tue, 16 Jan 2018 11:51:53 +0100 >

Re: elf.h: define SHT_SYMTAB_SHNDX

ping. The addition of SHT_SYMTAB_SHNDX is not just estetic improvement but fixes GHC HEAD build failure on OpenBSD 6.2-current. Hence pinging. Thanks! Karel On Tue, 16 Jan 2018 11:51:53 +0100 Martin Pieuchot wrote: > On 15/01/18(Mon) 23:11, Karel Gardas wrote: > > patch

Re: elf.h: define SHT_SYMTAB_SHNDX

On 16/01/18(Tue) 14:17, Karel Gardas wrote: > [...] > The patch looks good if you are OK with adding values which are no longer in > spec. IMHO I do not see value in those, What if somebody use them in their code? Removing them would break their app for free. That's why I see value in those ;)

Re: elf.h: define SHT_SYMTAB_SHNDX

On 01/16/18 11:51, Martin Pieuchot wrote: On 15/01/18(Mon) 23:11, Karel Gardas wrote: patch below defines SHT_SYMTAB_SHNDX which is required for usage of SHN_XINDEX which got added/defined during October 2017 by mpi. See: http://www.sco.com/developers/gabi/latest/ch4.sheader.html:

Re: elf.h: define SHT_SYMTAB_SHNDX

On 15/01/18(Mon) 23:11, Karel Gardas wrote: > patch below defines SHT_SYMTAB_SHNDX which is required for usage of > SHN_XINDEX which got added/defined during October 2017 by mpi. > > See: http://www.sco.com/developers/gabi/latest/ch4.sheader.html: > > SHT_SYMTAB_SHNDX > This section is

elf.h: define SHT_SYMTAB_SHNDX

Hello, patch below defines SHT_SYMTAB_SHNDX which is required for usage of SHN_XINDEX which got added/defined during October 2017 by mpi. See: http://www.sco.com/developers/gabi/latest/ch4.sheader.html: SHT_SYMTAB_SHNDX This section is associated with a symbol table section and is

Re: elf_abi.h -> elf.h

On Fri, Oct 27 2017, Martin Pieuchot wrote: > I'd like to get rid of which is not portable at all. > > is at least present on Solaris, FreeBSD and OSX. > > ok? ok -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE

elf_abi.h -> elf.h

I'd like to get rid of which is not portable at all. is at least present on Solaris, FreeBSD and OSX. ok? Index: games/hangman/ksyms.c === RCS file: /cvs/src/games/hangman/ksyms.c,v retrieving revision 1.10 diff -u -p -r1.10

Re: elf.h

Hi, below is last version of my attempt to migrate elf_abi.h to elf.h. This version solves devel/libdwarf and devel/valgrind failures reported on ports@ by Christian Weisgerber Thanks, Karel ? .cvsignore Index: distrib/sets/lists/comp/mi

Re: elf.h

Hi, the diff below is generated by CVS. For this I removed include/elf_abi.h and added include/elf.h. I've also merged two _KERNEL sections together and fixed platforms ld.so/*/archdep.h files for inclusion of elf_abi.h. Otherwise the description from previous version still apply. Karel

Re: elf.h

> So with this base is compilable and runnable on AMD64. W.r.t. ports, yes, > some of those fails. I've not investigated more closely strange failures > which may be a cause of me not cleaning up fs from previous snapshots -- this > machine is basically 2 years old snapshots accumulation

Re: elf.h

s from previous snapshots -- this > machine is basically 2 years old snapshots accumulation withought files > removal (ports failing: thunderbird, seamonkey, tor-browser, poco, pypy). But > some failures are clearly result of the work: libdwarf -- conflicts with ELF > types due to presence o

Re: elf.h

Hi, below is another diff of my elf.h cleanup work. I'm still keeping /usr/include/elf_abi.h to not break GHC and all Haskell based ports. What I have done in this version is went thorough whole spec and check everything in the exec_elf.h. What's not in spec I commented out with "not in

Re: elf.h

cept few exceptions. I used ELF_OPENBSD_EXTENSION for > those. Anyway, both toolchains (bintils+gcc/llvm+clang) seem to live their > own ELF lifes without even attempting to include system elf.h/elf_abi.h so > they are clean and not touched. So we should maybe just replace by , an

Re: elf.h

question is if this hurts or not. > What would it take to convert base programs to ? Base is quite clean except few exceptions. I used ELF_OPENBSD_EXTENSION for those. Anyway, both toolchains (bintils+gcc/llvm+clang) seem to live their own ELF lifes without even attempting to include system elf.

Re: elf.h

Hello, On 03/07/17(Mon) 18:58, Karel Gardas wrote: > I'm curious if it's possible to provide /usr/include/elf.h file on OpenBSD to > improve its niceness to software porting from other Unixes. Following patch > adds this for me and is tested with GHC where I'd like to kill

elf.h

Hello, I'm curious if it's possible to provide /usr/include/elf.h file on OpenBSD to improve its niceness to software porting from other Unixes. Following patch adds this for me and is tested with GHC where I'd like to kill code like: #if !defined(openbsd_HOST_OS) # include #else