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 Raadt
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
>
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 below defines SHT_SYMT
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 ;)
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:
SHT_SYMTA
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 assoc
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 require
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
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 ksyms
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
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.
Kare
> 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 withoug
pshots -- 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 of elf.h. I
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 &q
ould 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.h/e
e 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.h/elf_abi.h so
> they are clean and not touched.
So we should maybe just replac
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.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
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)
#
19 matches
Mail list logo