Re: Porting skalibs to GNU Hurd

From: Laurent Bercot <ska-skaware_at_skarnet.org>
Date: Wed, 16 Oct 2019 17:02:45 +0000

  Hi Shengjing,


>With using `CPPFLAGS += -D_GNU_SOURCE -DPATH_MAX=4096`,
>skalibs builds on Hurd, execline works fine. (Though I failed to run s6.)

What problems did you get with s6? It should be able to run without
trouble. To me that's a more important issue than the ones you listed
below. :)


>Here are the problems of skalibs:
>
>1. In src/include/skalibs/nonposix.h,
>
>#if defined(__linux__) || defined(__GLIBC__)
>The if condition seems not working. Of course it's not __linux__, but I am
>using glibc.

Ah, yes, __GLIBC__ is only defined in features.h, you're right.

That is a problem, because features.h is not POSIX, so I can't rely on
this file existing - especially in a header explicitly designed to
gather workarounds to non-POSIXness. So #include <features.h> is just
not possible. And I can't #include any standard headers such as
sys/types.h either, because the macros defined by skalibs/nonposix.h
must appear *before* standard header inclusion.

Do you have any idea on how to work around this? The only thing I can
see is to #define _GNU_SOURCE (and other macros for other systems)
unconditionally, but that's a bit annoying. I'll do it if there's no
other solution though.


>2. No PATH_MAX macro
>
>https://www.gnu.org/software/hurd/hurd/porting/guidelines.html

  Ugh, that's a tough one, and indeed relies on a very precise reading
of the limits.h specification. I had no idea the limits defined in
limits.h were optional; and they really shouldn't be. Dynamic allocation
is much heavier than stack allocation and shouldn't be made mandatory.
skaware relies on PATH_MAX, and a couple other limits, here and there;
I can't promise I'll fix them all, especially if getting rid of PATH_MAX
would introduce dynamic allocation in a place where there is currently
none, or if it would require a change of public API.

  If you manage to build skaware on Hurd with -DPATH_MAX=4096, that's
honestly good enough for me (and if things break when people have fun
with longer absolute paths, that's on them and they can recompile with
8192 instead). What I can promise is to fix every issue that you might
get with -DPATH_MAX=4096. And remove the dependencies on PATH_MAX that
can be removed painlessly. How does that sound?

--
  Laurent
Received on Wed Oct 16 2019 - 17:02:45 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:38:49 UTC