Hi Sam,
I don't know whether the files were ever submitted upstream. The files date
from 2002. HP stopped
supporting PA-RISC work at Redhat somewhere around that time.
Anyway, the errors don't look hard to fix. Do you want to take a crack at a
patch?
Regards,
Dave
On 2022-02-01 9:38 p.m., Sam James wrote:
HI,
I'm not a Debian user but Gentoo (from where I hail) is the only other distro
AFAIK still supporting HPPA, so I like
to look at what Debian is doing for some packages.
I noticed elfutils upstream lacks HPPA support but saw Debian has a HPPA
backend patch [0].
Two questions:
1. Has this been attempted to be upstreamed before? Any known problems with it?
2. I'm not sure it's actually being used in Debian despite being applied(?)
The backends/Makefile.am changes seem to be missing a hunk(?):
```
--- a/backends/Makefile.am
+++ b/backends/Makefile.am
@@ -102,7 +102,7 @@ libebl_backends_a_SOURCES = $(i386_SRCS) $(sh_SRCS)
$(x86_64_SRCS) \
$(ia64_SRCS) $(alpha_SRCS) $(arm_SRCS) \
$(aarch64_SRCS) $(sparc_SRCS) $(ppc_SRCS) \
$(ppc64_SRCS) $(s390_SRCS) \
- $(m68k_SRCS) $(bpf_SRCS) $(riscv_SRCS) $(csky_SRCS)
+ $(m68k_SRCS) $(bpf_SRCS) $(riscv_SRCS) $(csky_SRCS)
$(parisc_SRCS)
libebl_backends_pic_a_SOURCES =
am_libebl_backends_pic_a_OBJECTS = $(libebl_backends_a_SOURCES:.c=.os)
```
Without adding this to a local build in Gentoo, the PARISC files added by the
patch
aren't built at all.
I don't see any reference to the files in the build log for Debian either [1].
But when I add this t Makefile.am anyway, I end up with a build failure:
```
/var/tmp/portage/dev-libs/elfutils-0.186/work/elfutils-0.186/backends/parisc_init.c:41:1:
error: conflicting types for ‘parisc_init’; have ‘const char *(Elf *,
GElf_Half, Ebl *, size_t)’ {aka ‘const char *
(Elf *, short unsigned int, struct ebl *, unsigned int)’}
41 | parisc_init (Elf *elf __attribute__ ((unused)),
| ^~~~~~~~~~~
In file included from
/var/tmp/portage/dev-libs/elfutils-0.186/work/elfutils-0.186/backends/parisc_init.c:33:
/var/tmp/portage/dev-libs/elfutils-0.186/work/elfutils-0.186/backends/parisc_init.c:31:25:
note: previous declaration of ‘parisc_init’ with type ‘Ebl *(Elf *, GElf_Half,
Ebl *)’ {aka ‘struct ebl *(Elf *, short unsigned int, struct ebl *)’}
31 | #define BACKEND parisc_
| ^~~~~~~
/var/tmp/portage/dev-libs/elfutils-0.186/work/elfutils-0.186/backends/libebl_CPU.h:37:25:
note: in definition of macro ‘EBLHOOK_2’
37 | #define EBLHOOK_2(a, b) a##b
| ^
/var/tmp/portage/dev-libs/elfutils-0.186/work/elfutils-0.186/backends/libebl_CPU.h:35:25:
note: in expansion of macro ‘EBLHOOK_1’
35 | #define EBLHOOK(name) EBLHOOK_1(BACKEND, name)
| ^~~~~~~~~
/var/tmp/portage/dev-libs/elfutils-0.186/work/elfutils-0.186/backends/libebl_CPU.h:35:35:
note: in expansion of macro ‘BACKEND’
35 | #define EBLHOOK(name) EBLHOOK_1(BACKEND, name)
| ^~~~~~~
/var/tmp/portage/dev-libs/elfutils-0.186/work/elfutils-0.186/backends/libebl_CPU.h:40:13:
note: in expansion of macro ‘EBLHOOK’
40 | extern Ebl *EBLHOOK(init) (Elf *elf, GElf_Half machine, Ebl *eh);
| ^~~~~~~
/var/tmp/portage/dev-libs/elfutils-0.186/work/elfutils-0.186/backends/parisc_init.c:
In function ‘parisc_init’:
/var/tmp/portage/dev-libs/elfutils-0.186/work/elfutils-0.186/backends/parisc_init.c:59:5:
error: ‘Ebl’ {aka ‘struct ebl’} has no member named ‘name’
59 | eh->name = "PA-RISC";
| ^~
/var/tmp/portage/dev-libs/elfutils-0.186/work/elfutils-0.186/backends/parisc_init.c:72:10:
error: ‘MODVERSION’ undeclared (first use in this function); did you mean
‘OLD_VERSION’?
72 | return MODVERSION;
| ^~~~~~~~~~
| OLD_VERSION
/var/tmp/portage/dev-libs/elfutils-0.186/work/elfutils-0.186/backends/parisc_init.c:72:10:
note: each undeclared identifier is reported only once for each function it
appears in
/var/tmp/portage/dev-libs/elfutils-0.186/work/elfutils-0.186/backends/parisc_init.c:73:1:
warning: control reaches end of non-void function [-Wreturn-type]
73 | }
| ^
```
[0]
https://sources.debian.org/src/elfutils/0.186-1/debian/patches/hppa_backend.diff/
[1]
https://buildd.debian.org/status/fetch.php?pkg=elfutils&arch=hppa&ver=0.186-1&stamp=1637187997&raw=0
Best,
sam
--
John David Anglin [email protected]