NetBSD Problem Report #50166
From www@NetBSD.org Mon Aug 24 17:50:13 2015
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
by mollari.NetBSD.org (Postfix) with ESMTPS id C3D4DA65D1
for <gnats-bugs@gnats.NetBSD.org>; Mon, 24 Aug 2015 17:50:12 +0000 (UTC)
Message-Id: <20150824175009.D8C88A65E2@mollari.NetBSD.org>
Date: Mon, 24 Aug 2015 17:50:09 +0000 (UTC)
From: rmh@gnu.org
Reply-To: rmh@gnu.org
To: gnats-bugs@NetBSD.org
Subject: [PATCH] MAXPATHLEN / PATH_MAX definitions (for GNU/Hurd support in Rump)
X-Send-Pr-Version: www-1.0
>Number: 50166
>Category: misc
>Synopsis: [PATCH] MAXPATHLEN / PATH_MAX definitions (for GNU/Hurd support in Rump)
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: pooka
>State: closed
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Mon Aug 24 17:55:00 +0000 2015
>Closed-Date: Thu Sep 24 00:40:42 +0000 2015
>Last-Modified: Thu Sep 24 00:50:00 +0000 2015
>Originator: Robert Millan
>Release: HEAD
>Organization:
>Environment:
>Description:
GNU/Hurd doesn't have PATH_MAX or MAXHOSTNAMELEN (arbitrarily long strings can be used). Since attempting to replace every instance of static allocation with dynamic buffer management would make for a very intrusive patch, I'm proposing to just define the limits as alternative.
I took care to use the same limits Rump namespace has, just to avoid accidental cross-definition of a different value causing damage somewhere (e.g. overflows or such).
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
From: Robert Millan <rmh@gnu.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: misc/50166: [PATCH] MAXPATHLEN / PATH_MAX definitions (for GNU/Hurd
support in Rump)
Date: Mon, 24 Aug 2015 20:11:37 +0200
This is a multi-part message in MIME format.
--------------000702000804050103070600
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
El 24/08/15 a les 19:55, gnats-admin@netbsd.org ha escrit:
> Thank you very much for your problem report.
> It has the internal identification `misc/50166'.
> The individual assigned to look at your
> report is: misc-bug-people.
>
>> Category: misc
>> Responsible: misc-bug-people
>> Synopsis: [PATCH] MAXPATHLEN / PATH_MAX definitions (for GNU/Hurd support in Rump)
>> Arrival-Date: Mon Aug 24 17:55:00 +0000 2015
Thanks. Here's the patch.
--
Robert Millan
--------------000702000804050103070600
Content-Type: text/x-patch;
name="hurd_3_limits.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="hurd_3_limits.diff"
--- a/src/tools/compat/Makefile
+++ b/src/tools/compat/Makefile
@@ -38,6 +38,11 @@
CPPFLAGS+= -I. -I./include -I${.CURDIR} -I${.CURDIR}/sys \
-DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64
+# Define MAXPATHLEN limit on GNU/Hurd
+.if ${BUILD_OSTYPE} == "GNU"
+CPPFLAGS+= -DMAXPATHLEN=1024 -DPATH_MAX=1024
+.endif
+
.PATH: ${.CURDIR}/../../lib/libc/cdb \
${.CURDIR}/../../lib/libc/gen \
${.CURDIR}/../../lib/libc/hash \
--- a/src/tools/compat/defs.mk.in
+++ b/src/tools/compat/defs.mk.in
@@ -79,6 +79,11 @@
HOST_CPPFLAGS+= ${COMPATINCFLAGS} -I${NETBSDSRCDIR}/tools/compat \
-DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64
+# Define MAXPATHLEN limit on GNU/Hurd
+.if ${BUILD_OSTYPE} == "GNU"
+HOST_CPPFLAGS+= -DMAXPATHLEN=1024 -DPATH_MAX=1024
+.endif
+
.if "${COMPATLIB_NO_LIB}" != "yes"
DPADD+= ${COMPATLIBDIR}/libnbcompat.a
LDADD+= -L${COMPATLIBDIR} -lnbcompat @LIBS@
--- a/src/tools/make/configure
+++ b/src/tools/make/configure
@@ -971,6 +971,10 @@
#define DEFSHELL_CUSTOM "${BSHELL}"
EOF
+cat >>confdefs.h <<EOF
+#define MAXPATHLEN 1024
+EOF
+
# Make sure we have POSIX regex ability.
ac_ext=c
ac_cpp='$CPP $CPPFLAGS'
--- a/src/tools/make/configure.ac
+++ b/src/tools/make/configure.ac
@@ -24,6 +24,7 @@
AC_INIT([make], [noversion], [bin-bug-people@NetBSD.org])
AC_CONFIG_FILES(buildmake.sh)
+AC_CANONICAL_HOST()
AC_PATH_PROG(BSHELL, sh)
if test x"$BSHELL" = x; then
@@ -31,6 +32,13 @@
fi
AC_DEFINE_UNQUOTED(DEFSHELL_CUSTOM, "${BSHELL}")
+case $host_os in
+ gnu*)
+ # Define MAXPATHLEN limit on GNU/Hurd
+ AC_DEFINE_UNQUOTED(MAXPATHLEN, 1024)
+ ;;
+esac
+
# Make sure we have POSIX regex ability.
AC_CHECK_HEADER(regex.h,, AC_MSG_ERROR([POSIX regex.h is required]))
--------------000702000804050103070600--
From: Robert Millan <rmh@gnu.org>
To: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, rmh@gnu.org
Cc:
Subject: Re: misc/50166: [PATCH] MAXPATHLEN / PATH_MAX definitions (for GNU/Hurd
support in Rump)
Date: Mon, 24 Aug 2015 23:05:07 +0200
El 24/08/15 a les 21:20, Robert Millan ha escrit:
> --- a/src/tools/make/configure
> +++ b/src/tools/make/configure
> @@ -971,6 +971,10 @@
> #define DEFSHELL_CUSTOM "${BSHELL}"
> EOF
>
> +cat >>confdefs.h <<EOF
> +#define MAXPATHLEN 1024
> +EOF
> +
> # Make sure we have POSIX regex ability.
> ac_ext=c
> ac_cpp='$CPP $CPPFLAGS'
As I assume you re-generate configure from configure.ac, this part was ment
to be editted out before submitting. Sorry for the oversight ;-)
--
Robert Millan
From: Antti Kantee <pooka@iki.fi>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: misc/50166
Date: Wed, 26 Aug 2015 12:02:00 +0000
Adding AC_CANONICAL_HOST() to configure.ac makes configure fail because
a reference to install-sh is generated (and install-sh is not present).
From: Robert Millan <rmh@gnu.org>
To: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: Re: misc/50166
Date: Fri, 28 Aug 2015 19:00:28 +0200
El 26/08/15 a les 14:05, Antti Kantee ha escrit:
> The following reply was made to PR misc/50166; it has been noted by GNATS.
>
> From: Antti Kantee <pooka@iki.fi>
> To: gnats-bugs@NetBSD.org
> Cc:
> Subject: Re: misc/50166
> Date: Wed, 26 Aug 2015 12:02:00 +0000
>
> Adding AC_CANONICAL_HOST() to configure.ac makes configure fail because
> a reference to install-sh is generated (and install-sh is not present).
>
> ....
> So, I tried it, and indeed there was fallout from AC_CANONICAL_HOST() (as noted in the PR). Can you try to work around it somehow? src/tools/make/configure.ac contains the official way to regenerate configure.
If you want to keep it simple, I could switch it to use uname instead of AC_CANONICAL_HOST(). It
will break cross-compiling but AFAICS the whole purpose of this script is to bootstrap make on
non-NetBSD systems, which is a very native-build oriented end, and I doubt cross-compiling was
ever intended to work here anyways.
Does that sound good?
--
Robert Millan
From: Antti Kantee <pooka@iki.fi>
To: Robert Millan <rmh@gnu.org>, gnats-bugs@NetBSD.org,
misc-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: Re: misc/50166
Date: Sun, 30 Aug 2015 23:14:38 +0000
On 28/08/15 17:00, Robert Millan wrote:
> El 26/08/15 a les 14:05, Antti Kantee ha escrit:
>> The following reply was made to PR misc/50166; it has been noted by
>> GNATS.
>>
>> From: Antti Kantee <pooka@iki.fi>
>> To: gnats-bugs@NetBSD.org
>> Cc:
>> Subject: Re: misc/50166
>> Date: Wed, 26 Aug 2015 12:02:00 +0000
>>
>> Adding AC_CANONICAL_HOST() to configure.ac makes configure fail because
>> a reference to install-sh is generated (and install-sh is not present).
>>
> > ....
> > So, I tried it, and indeed there was fallout from AC_CANONICAL_HOST()
> (as noted in the PR). Can you try to work around it somehow?
> src/tools/make/configure.ac contains the official way to regenerate
> configure.
>
> If you want to keep it simple, I could switch it to use uname instead of
> AC_CANONICAL_HOST(). It
> will break cross-compiling but AFAICS the whole purpose of this script
> is to bootstrap make on
> non-NetBSD systems, which is a very native-build oriented end, and I
> doubt cross-compiling was
> ever intended to work here anyways.
>
> Does that sound good?
I assume you mean cross-compiling in the Canadian sense, i.e. building
the tools for another system. I don't know if that works or is intended
to work. You can ask tech-toolchain@netbsd.org and observe the outcry
or lack thereof.
Testing for availability of MAXPATHLEN would be better, though. I guess
you can just look at some tool using MAXPATHLEN and determine what you
need to include so that you can test if it's available or not.
From: Robert Millan <rmh@gnu.org>
To: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, rmh@gnu.org
Cc:
Subject: Re: misc/50166
Date: Fri, 11 Sep 2015 01:04:08 +0200
This is a multi-part message in MIME format.
--------------010702000706090604010000
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
El 31/08/15 a les 01:15, Antti Kantee ha escrit:
> > If you want to keep it simple, I could switch it to use uname instead of
> > AC_CANONICAL_HOST(). It
> > will break cross-compiling but AFAICS the whole purpose of this script
> > is to bootstrap make on
> > non-NetBSD systems, which is a very native-build oriented end, and I
> > doubt cross-compiling was
> > ever intended to work here anyways.
> >
> > Does that sound good?
>
> I assume you mean cross-compiling in the Canadian sense, i.e. building
> the tools for another system. I don't know if that works or is intended
> to work. You can ask tech-toolchain@netbsd.org and observe the outcry
> or lack thereof.
>
> Testing for availability of MAXPATHLEN would be better, though. I guess
> you can just look at some tool using MAXPATHLEN and determine what you
> need to include so that you can test if it's available or not.
Hi,
I just realized there's a much simpler way around this, if we want to test for
MAXPATHLEN as you suggest, autoconf really isn't necessary as it can be done
directly in C pre-processor.
See attached patch, please let me know what you think.
--
Robert Millan
--------------010702000706090604010000
Content-Type: text/x-patch;
name="maxpathlen.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="maxpathlen.diff"
Index: rumpkernel-0~20150715/buildrump.sh/src/usr.bin/make/make.h
===================================================================
--- rumpkernel-0~20150715.orig/buildrump.sh/src/usr.bin/make/make.h 2015-07-23 22:54:05.000000000 +0200
+++ rumpkernel-0~20150715/buildrump.sh/src/usr.bin/make/make.h 2015-09-05 12:31:02.556270631 +0200
@@ -503,4 +503,11 @@
#define MAX(a, b) ((a > b) ? a : b)
#endif
+/* GNU/Hurd systems lack MAXPATHLEN */
+#include <limits.h>
+#ifndef MAXPATHLEN
+#warning "MAXPATHLEN undefined on this system, forcing an arbitrary limit"
+#define MAXPATHLEN 4096
+#endif
+
#endif /* _MAKE_H_ */
--------------010702000706090604010000--
Responsible-Changed-From-To: misc-bug-people->pooka
Responsible-Changed-By: pooka@NetBSD.org
Responsible-Changed-When: Fri, 18 Sep 2015 12:40:13 +0000
Responsible-Changed-Why:
make me responsible so that I get email notifications about replies
State-Changed-From-To: open->analyzed
State-Changed-By: pooka@NetBSD.org
State-Changed-When: Fri, 18 Sep 2015 12:40:13 +0000
State-Changed-Why:
problem known
From: Antti Kantee <pooka@NetBSD.org>
To: Robert Millan <rmh@gnu.org>
Cc: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/50166
Date: Fri, 18 Sep 2015 12:57:35 +0000
On Fri, Sep 11, 2015 at 01:04:08AM +0200, Robert Millan wrote:
> I just realized there's a much simpler way around this, if we want to test for
> MAXPATHLEN as you suggest, autoconf really isn't necessary as it can be done
> directly in C pre-processor.
>
> See attached patch, please let me know what you think.
Even if make is the only thing in tools currently using MAXPATHLEN,
could we put the compat value into tools/compat/compat_defs.h
instead?
Apart from that, the approach seems ok.
> Index: rumpkernel-0~20150715/buildrump.sh/src/usr.bin/make/make.h
> ===================================================================
> --- rumpkernel-0~20150715.orig/buildrump.sh/src/usr.bin/make/make.h 2015-07-23 22:54:05.000000000 +0200
> +++ rumpkernel-0~20150715/buildrump.sh/src/usr.bin/make/make.h 2015-09-05 12:31:02.556270631 +0200
> @@ -503,4 +503,11 @@
> #define MAX(a, b) ((a > b) ? a : b)
> #endif
>
> +/* GNU/Hurd systems lack MAXPATHLEN */
> +#include <limits.h>
> +#ifndef MAXPATHLEN
> +#warning "MAXPATHLEN undefined on this system, forcing an arbitrary limit"
> +#define MAXPATHLEN 4096
> +#endif
> +
> #endif /* _MAKE_H_ */
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: misc/50166
Date: Fri, 18 Sep 2015 14:22:54 +0000
On Fri, Sep 18, 2015 at 01:00:01PM +0000, Antti Kantee wrote:
> > See attached patch, please let me know what you think.
>
> Even if make is the only thing in tools currently using MAXPATHLEN,
> could we put the compat value into tools/compat/compat_defs.h
> instead?
>
> Apart from that, the approach seems ok.
Well, it should be changed to PATH_MAX, which is posix.
--
David A. Holland
dholland@netbsd.org
From: Antti Kantee <pooka@NetBSD.org>
To: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
rmh@gnu.org
Cc:
Subject: Re: misc/50166
Date: Fri, 18 Sep 2015 14:42:26 +0000
On 18/09/15 14:25, David Holland wrote:
> Well, it should be changed to PATH_MAX, which is posix.
Yes, standardized, but I read the standard so that PATH_MAX is not
required to be defined by limits.h:
"The values in the following list may be constants within an
implementation or may vary from one pathname to another. For example,
file systems or directories may have different characteristics.
A definition of one of the values shall be omitted from the <limits.h>
header on specific implementations where the corresponding value is
equal to or greater than the stated minimum, but where the value can
vary depending on the file to which it is applied. The actual value
supported for a specific pathname shall be provided by the pathconf()
function."
Notably, not just may be omitted, but shall be omitted.
Anyway, if Hurd does define PATH_MAX, we can use it, but if not,
changing the identifier doesn't solve anything no matter what the
standard says.
From: Robert Millan <rmh@gnu.org>
To: Antti Kantee <pooka@NetBSD.org>, gnats-bugs@NetBSD.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: Re: misc/50166
Date: Fri, 18 Sep 2015 21:23:33 +0200
El 18/09/15 a les 16:42, Antti Kantee ha escrit:
> Anyway, if Hurd does define PATH_MAX, we can use it, but if not, changing the identifier doesn't solve anything no matter what the standard says.
It defines neither PATH_MAX nor MAXPATHLEN (pathnames can be arbitrarily long).
--
Robert Millan
From: Robert Millan <rmh@gnu.org>
To: Antti Kantee <pooka@NetBSD.org>, Robert Millan <rmh@gnu.org>
Cc: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/50166
Date: Fri, 18 Sep 2015 22:25:23 +0200
El 18/09/15 a les 14:57, Antti Kantee ha escrit:
> On Fri, Sep 11, 2015 at 01:04:08AM +0200, Robert Millan wrote:
>> I just realized there's a much simpler way around this, if we want to test for
>> MAXPATHLEN as you suggest, autoconf really isn't necessary as it can be done
>> directly in C pre-processor.
>>
>> See attached patch, please let me know what you think.
>
> Even if make is the only thing in tools currently using MAXPATHLEN,
> could we put the compat value into tools/compat/compat_defs.h
> instead?
>
> Apart from that, the approach seems ok.
compat_defs.h doesn't seem to help as make.h does:
/home/amnesia/rump/debian/rumpkernel/buildrump.sh/src/tools/make/../../usr.bin/make/arch.c: In function 'ArchSVR4Entry':
/home/amnesia/rump/debian/rumpkernel/buildrump.sh/src/tools/make/../../usr.bin/make/arch.c:815:47: error: 'MAXPATHLEN' undeclared (first use in this function)
(void)strncpy(name, &ar->fnametab[entry], MAXPATHLEN);
what is the expected include path for arch.c -> compat_defs.h?
--
--
Robert Millan
From: Antti Kantee <pooka@NetBSD.org>
To: Robert Millan <rmh@gnu.org>
Cc: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/50166
Date: Sat, 19 Sep 2015 13:27:54 +0000
On 18/09/15 20:25, Robert Millan wrote:
> compat_defs.h doesn't seem to help as make.h does:
>
> /home/amnesia/rump/debian/rumpkernel/buildrump.sh/src/tools/make/../../usr.bin/make/arch.c:
> In function 'ArchSVR4Entry':
> /home/amnesia/rump/debian/rumpkernel/buildrump.sh/src/tools/make/../../usr.bin/make/arch.c:815:47:
> error: 'MAXPATHLEN' undeclared (first use in this function)
> (void)strncpy(name, &ar->fnametab[entry], MAXPATHLEN);
>
> what is the expected include path for arch.c -> compat_defs.h?
Try adding:
#if HAVE_NBTOOL_CONFIG_H
#include "nbtool_config.h"
#endif
to the appropriate place(s).
From: Robert Millan <rmh@gnu.org>
To: Antti Kantee <pooka@NetBSD.org>
Cc: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/50166
Date: Sun, 20 Sep 2015 14:20:14 +0200
Hi,
El 19/09/15 a les 15:27, Antti Kantee ha escrit:
> On 18/09/15 20:25, Robert Millan wrote:
>> compat_defs.h doesn't seem to help as make.h does:
>>
>> /home/amnesia/rump/debian/rumpkernel/buildrump.sh/src/tools/make/../../usr.bin/make/arch.c:
>> In function 'ArchSVR4Entry':
>> /home/amnesia/rump/debian/rumpkernel/buildrump.sh/src/tools/make/../../usr.bin/make/arch.c:815:47:
>> error: 'MAXPATHLEN' undeclared (first use in this function)
>> (void)strncpy(name, &ar->fnametab[entry], MAXPATHLEN);
>>
>> what is the expected include path for arch.c -> compat_defs.h?
>
> Try adding:
>
> #if HAVE_NBTOOL_CONFIG_H
> #include "nbtool_config.h"
> #endif
>
> to the appropriate place(s).
I don't think this can work. Looking at the log, make is initially compiled before running
build.sh, then build.sh uses make to build other stuff, and then nbtool_config.h is
dynamically generated by src/tools/compat/configure.
Can we make an exception for make and put the MAXPATHLEN ifdef in make.h too?
--
Robert Millan
From: Antti Kantee <pooka@NetBSD.org>
To: Robert Millan <rmh@gnu.org>
Cc: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/50166
Date: Sun, 20 Sep 2015 12:48:21 +0000
On 20/09/15 12:20, Robert Millan wrote:
>>> what is the expected include path for arch.c -> compat_defs.h?
>>
>> Try adding:
>>
>> #if HAVE_NBTOOL_CONFIG_H
>> #include "nbtool_config.h"
>> #endif
>>
>> to the appropriate place(s).
>
> I don't think this can work. Looking at the log, make is initially
> compiled before running
> build.sh, then build.sh uses make to build other stuff, and then
> nbtool_config.h is
> dynamically generated by src/tools/compat/configure.
>
> Can we make an exception for make and put the MAXPATHLEN ifdef in make.h
> too?
You don't think it can work, or you tested it => it didn't work, and you
think there's a fundamental flaw in the scheme?
We can address make separately too if need be. Do you still need the
bits in compat/{Makefile,defs.mk.in}? Can those be addressed by using
compat_defs.h instead of hardcoding the values based on uname -s? Or
does that require including nbtool_config.h from a large number of .c files?
From: Robert Millan <rmh@gnu.org>
To: Antti Kantee <pooka@NetBSD.org>
Cc: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/50166
Date: Sun, 20 Sep 2015 15:19:34 +0200
El 20/09/15 a les 14:48, Antti Kantee ha escrit:
> On 20/09/15 12:20, Robert Millan wrote:
>>>> what is the expected include path for arch.c -> compat_defs.h?
>>>
>>> Try adding:
>>>
>>> #if HAVE_NBTOOL_CONFIG_H
>>> #include "nbtool_config.h"
>>> #endif
>>>
>>> to the appropriate place(s).
>>
>> I don't think this can work. Looking at the log, make is initially
>> compiled before running
>> build.sh, then build.sh uses make to build other stuff, and then
>> nbtool_config.h is
>> dynamically generated by src/tools/compat/configure.
>>
>> Can we make an exception for make and put the MAXPATHLEN ifdef in make.h
>> too?
>
> You don't think it can work, or you tested it => it didn't work, and you think there's a fundamental flaw in the scheme?
I tested it and it didn't work, then I noticed the chicken & egg problem. Sorry I wasn't clear enough.
> Do you still need the bits in compat/{Makefile,defs.mk.in}? Can those be addressed by using compat_defs.h instead of hardcoding the values based on uname -s? Or does that require including nbtool_config.h from a large number of .c files?
Possibly not. I'll check and get back to you.
Thanks
--
Robert Millan
From: Martin Husemann <martin@duskware.de>
To: Robert Millan <rmh@gnu.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: misc/50166
Date: Sun, 20 Sep 2015 16:56:39 +0200
Maybe we should even do something more radical and follow Plan9 completely
(in make) by eliminating all size limited path name buffers?
Should not be too hard, and conceptionally make has no purpose to know about
varying and arbitrary path limits.
Martin
P.S.: but I understand you are looking for a quick/interim solution to get
things going, that is fine too.
From: Robert Millan <rmh@gnu.org>
To: Antti Kantee <pooka@NetBSD.org>
Cc: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/50166
Date: Mon, 21 Sep 2015 22:37:13 +0200
This is a multi-part message in MIME format.
--------------030703000301090409070001
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
El 20/09/15 a les 14:48, Antti Kantee ha escrit:
> We can address make separately too if need be. Do you still need the bits in compat/{Makefile,defs.mk.in}? Can those be addressed by using compat_defs.h instead of hardcoding the values based on uname -s? Or does that require including nbtool_config.h from a large number of .c files?
As you suggested, I took a closer inspection by disabling all the generic -D flags and
using nbtool_config.h instead.
Then I added back only the defines that were needed in the corresponding individual
files.
The result is much smaller than I expected. In fact, other than make (because of the
bootstrap issue) and some Rump components, all remaining MAXPATHLEN/etc issues are
handled by nbtool_config.h.
Please consider attached patch.
--
Robert Millan
--------------030703000301090409070001
Content-Type: text/x-patch;
name="limits.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="limits.diff"
Index: rumpkernel/buildrump.sh/src/usr.bin/make/make.h
===================================================================
--- rumpkernel.orig/buildrump.sh/src/usr.bin/make/make.h
+++ rumpkernel/buildrump.sh/src/usr.bin/make/make.h
@@ -503,4 +503,10 @@ int str2Lst_Append(Lst, char *, const ch
#define MAX(a, b) ((a > b) ? a : b)
#endif
+/* GNU/Hurd systems lack MAXPATHLEN */
+#include <limits.h>
+#ifndef MAXPATHLEN
+#define MAXPATHLEN 4096
+#endif
+
#endif /* _MAKE_H_ */
Index: rumpkernel/buildrump.sh/src/tools/compat/compat_defs.h
===================================================================
--- rumpkernel.orig/buildrump.sh/src/tools/compat/compat_defs.h
+++ rumpkernel/buildrump.sh/src/tools/compat/compat_defs.h
@@ -1201,6 +1201,17 @@ __GEN_ENDIAN_DEC(64, le)
#define LINE_MAX 2048
#endif
+/* GNU/Hurd systems lack MAXPATHLEN (aka PATH_MAX) and MAXHOSTNAMELEN */
+#ifndef MAXPATHLEN
+#define MAXPATHLEN 4096
+#endif
+#ifndef PATH_MAX
+#define PATH_MAX MAXPATHLEN
+#endif
+#ifndef MAXHOSTNAMELEN
+#define MAXHOSTNAMELEN 256
+#endif
+
/* <sys/time.h> */
#ifndef timercmp
Index: rumpkernel/buildrump.sh/src/sys/rump/include/rump/rumpuser.h
===================================================================
--- rumpkernel.orig/buildrump.sh/src/sys/rump/include/rump/rumpuser.h
+++ rumpkernel/buildrump.sh/src/sys/rump/include/rump/rumpuser.h
@@ -251,4 +251,8 @@ int rumpuser_sp_raise(void *, int);
void rumpuser_sp_fini(void *);
#endif /* _RUMP_SYSPROXY || LIBRUMPUSER */
+#ifndef MAXHOSTNAMELEN
+#define MAXHOSTNAMELEN 256
+#endif
+
#endif /* _RUMP_RUMPUSER_H_ */
Index: rumpkernel/buildrump.sh/src/lib/librumpuser/sp_common.c
===================================================================
--- rumpkernel.orig/buildrump.sh/src/lib/librumpuser/sp_common.c
+++ rumpkernel/buildrump.sh/src/lib/librumpuser/sp_common.c
@@ -64,6 +64,10 @@
#define __unused __attribute__((__unused__))
#endif
+#ifndef PATH_MAX
+#define PATH_MAX 4096
+#endif
+
//#define DEBUG
#ifdef DEBUG
#define DPRINTF(x) mydprintf x
Index: rumpkernel/buildrump.sh/src/usr.bin/rump_allserver/rump_allserver.c
===================================================================
--- rumpkernel.orig/buildrump.sh/src/usr.bin/rump_allserver/rump_allserver.c
+++ rumpkernel/buildrump.sh/src/usr.bin/rump_allserver/rump_allserver.c
@@ -50,6 +50,10 @@ __RCSID("$NetBSD: rump_allserver.c,v 1.3
#include <rump/rumpdefs.h>
#include <rump/rumperr.h>
+#ifndef MAXPATHLEN
+#define MAXPATHLEN 4096
+#endif
+
__dead static void
usage(void)
{
--------------030703000301090409070001--
State-Changed-From-To: analyzed->feedback
State-Changed-By: pooka@NetBSD.org
State-Changed-When: Mon, 21 Sep 2015 21:54:39 +0000
State-Changed-Why:
patches potentially fixing the problem committed
From: "Antti Kantee" <pooka@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/50166 CVS commit: src
Date: Mon, 21 Sep 2015 21:50:16 +0000
Module Name: src
Committed By: pooka
Date: Mon Sep 21 21:50:16 UTC 2015
Modified Files:
src/lib/librumpuser: rumpuser_port.h
src/tools/compat: compat_defs.h
src/usr.bin/make: make.h
Log Message:
Add more compat defs for code compiled for !NetBSD targets.
At least GNU Hurd lacks MAXHOSTNAMELEN/MAXPATHLEN/PATH_MAX, so make sure
those have some arbitrary semi-sane values.
from Robert Millan in PR misc/50166, with some modifications from myself
To generate a diff of this commit:
cvs rdiff -u -r1.45 -r1.46 src/lib/librumpuser/rumpuser_port.h
cvs rdiff -u -r1.102 -r1.103 src/tools/compat/compat_defs.h
cvs rdiff -u -r1.95 -r1.96 src/usr.bin/make/make.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Antti Kantee <pooka@NetBSD.org>
To: Robert Millan <rmh@gnu.org>
Cc: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/50166
Date: Mon, 21 Sep 2015 21:53:31 +0000
On 21/09/15 20:37, Robert Millan wrote:
> The result is much smaller than I expected. In fact, other than make
> (because of the
> bootstrap issue) and some Rump components, all remaining MAXPATHLEN/etc
> issues are
> handled by nbtool_config.h.
>
> Please consider attached patch.
Ok I committed a variant of it (I moved the rump kernel userspace bits
into rumpuser_port.h). Please check if NetBSD HEAD now works for your
use case.
I'm also happy to apply a patch where MAXPATHLEN/PATH_MAX/MAXHOSTNAMELEN
is removed from the rump kernel userspace code, if you (or someone else)
want to send one in another PR.
From: Robert Millan <rmh@gnu.org>
To: Antti Kantee <pooka@NetBSD.org>
Cc: Bug hurd mailing list <bug-hurd@gnu.org>, gnats-bugs@NetBSD.org,
misc-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/50166
Date: Wed, 23 Sep 2015 23:25:48 +0200
El 21/09/15 a les 23:53, Antti Kantee ha escrit:
> On 21/09/15 20:37, Robert Millan wrote:
>> The result is much smaller than I expected. In fact, other than make
>> (because of the
>> bootstrap issue) and some Rump components, all remaining MAXPATHLEN/etc
>> issues are
>> handled by nbtool_config.h.
>>
>> Please consider attached patch.
>
> Ok I committed a variant of it (I moved the rump kernel userspace bits into rumpuser_port.h). Please check if NetBSD HEAD now works for your use case.
Well I'm glad to say I just tested, and current CVS HEAD builds correctly on GNU/Hurd now.
> I'm also happy to apply a patch where MAXPATHLEN/PATH_MAX/MAXHOSTNAMELEN is removed from the rump kernel userspace code, if you (or someone else) want to send one in another PR.
I think that would be nice having, but unfortunately I lack the spare time at the moment. CCing bug-hurd in case someone is interested.
Thanks!
--
Robert Millan
State-Changed-From-To: feedback->closed
State-Changed-By: pooka@NetBSD.org
State-Changed-When: Thu, 24 Sep 2015 00:40:42 +0000
State-Changed-Why:
submitter reported fixed
thanks for the report and patch!
From: Antti Kantee <pooka@NetBSD.org>
To: Robert Millan <rmh@gnu.org>
Cc: Bug hurd mailing list <bug-hurd@gnu.org>, gnats-bugs@NetBSD.org,
misc-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/50166
Date: Thu, 24 Sep 2015 00:44:54 +0000
On 23/09/15 21:25, Robert Millan wrote:
>> I'm also happy to apply a patch where
>> MAXPATHLEN/PATH_MAX/MAXHOSTNAMELEN is removed from the rump kernel
>> userspace code, if you (or someone else) want to send one in another PR.
>
> I think that would be nice having, but unfortunately I lack the spare
> time at the moment. CCing bug-hurd in case someone is interested.
Right, probably not highest priority now, since the code does work ...
unless someone wants to exercise their possibility to put it in a 8k
long subdirectory path on Hurd ;)
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.