bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 00/41] The x86_64 port


From: Sergey Bugaev
Subject: Re: [PATCH 00/41] The x86_64 port
Date: Wed, 10 May 2023 14:51:55 +0300

On Wed, May 10, 2023 at 1:43 PM Samuel Thibault <samuel.thibault@gnu.org> wrote:
> For now you'll just be faced with library dependencies, so I'd say just
> unpack all lib*.deb (+zlib1g*.deb) and you'll be done.

I see, thanks.

By the way, I'm now getting

../../isofs/lookup.c:224:1: error: conflicting types for
‘diskfs_get_directs’; have ‘error_t(struct node *, int,  int,  char
**, mach_msg_type_number_t *, vm_size_t,  int *)’ {aka ‘error_t(struct
node *, int,  int,  char **, unsigned int *, long unsigned int,  int
*)’}
  224 | diskfs_get_directs (struct node *dp,
      | ^~~~~~~~~~~~~~~~~~
In file included from ../include/hurd/diskfs.h:1,
                 from ../../isofs/isofs.h:24,
                 from ../../isofs/lookup.c:24:
../../isofs/../libdiskfs/diskfs.h:403:9: note: previous declaration of
‘diskfs_get_directs’ with type ‘error_t(struct node *, int,  int,
char **, size_t *, vm_size_t,  int *)’ {aka ‘error_t(struct node *,
int,  int,  char **, long unsigned int *, long unsigned int,  int *)’}
  403 | error_t diskfs_get_directs (struct node *dp, int entry, int n,
      |         ^~~~~~~~~~~~~~~~~~

which seems to be caused by your
cb5ab7708b6b7f9941a9ba914ede153601c5be49 "More prototypes fixes". Does
it build for you?

diskfs_get_directs is one of those functions that I decided not to
convert to use mach_msg_type_number_t in the API, and instead made the
caller (diskfs_S_dir_readdir) do the conversion. This can certainly be
reconsidered; but you'd have to update the definition in diskfs.h, all
the implementors, and revert the changes to diskfs_S_dir_readdir. Just
changing isofs won't work.

So other than that, it's now trying to execute /hurd/startup (with
Debian builds of everything but ext2fs.static and libpthread.so and
gnumach!) and getting ENOEXEC... probably because of the
ehdr->e_ident[EI_CLASS] != ELFCLASS32 check in exec/exec.c, and also
the elf_machine_matches_host thing.

To be continued.

Sergey



reply via email to

[Prev in Thread] Current Thread [Next in Thread]