Opened 18 months ago

Last modified 4 weeks ago

#62994 assigned defect

various ports fail to install on Leopard due to gnulib issue: /confdir-14B---: No space left on device

Reported by: kencu (Ken) Owned by: mascguy (Christopher Nielsen)
Priority: Normal Milestone:
Component: ports Version:
Keywords: leopard Cc: ballapete (Peter "Pete" Dyballa), barracuda156, acjones8 (Alex Jones), catap (Kirill A. Korinsky), amock (Alan Mock), khepler, cwoffenden (Carl Woffenden)
Port: m4 bison findutils coreutils

Description (last modified by kencu (Ken))

Interestingly, Tiger installed this without any trouble.

I also tried in trace mode, just in case, but same error. Disabling parallel builds didn't fix it either.

:info:configure config.status: creating po/Makefile
:info:configure rm: confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---: No space left on device
:info:configure rm: confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---: Directory not empty

Attachments (3)

m4-leopard-fail.log (99.1 KB) - added by kencu (Ken) 18 months ago.
deepdir.c (6.4 KB) - added by ballapete (Peter "Pete" Dyballa) 11 months ago.
Test programme of Paul Eggert from gnulib support
main.log.gz (12.3 KB) - added by kakuhen 5 months ago.
Attempted build of coreutils @9.1_0 on ppc leopard

Download all attachments as: .zip

Change History (42)

Changed 18 months ago by kencu (Ken)

Attachment: m4-leopard-fail.log added

comment:1 Changed 18 months ago by kencu (Ken)

Description: modified (diff)

comment:2 Changed 18 months ago by leavenode

I cleaned and attempted it again with the same issue. I'm thinking it must be something broken about that particular installation.

1.4.19_1 just installed fine on my other Tiger system, a G4 iBook.

comment:3 Changed 18 months ago by kencu (Ken)

Description: modified (diff)

comment:4 Changed 18 months ago by kencu (Ken)

For reasons I am not presently able to explain, m4 installed without trouble on the same Leopard system today.

All the other ports had finished updating. I installed it from a git repo rather than the usual default rsync repo. Otherwise I can't see anything that was changed.

My favourite kind of problem: intermittent, and inexplicable :>

comment:5 Changed 18 months ago by kencu (Ken)

Yuk -- just saw this again on another system, and no combo of disabling parallel builds, etc, fixed it.

The issue is coming, it seems, from a test in this file m4/getcwd-abort-bug.m4 that makes it's way into the configure script. I didn't spend hours on it, but it looks like they are looking for some kind of bug in libc on certain versions of linux, that shows up when PATH_MAX < getpagesize ();.

To get around it, I did this:

$ diff -u configure.old configure
--- configure.old	2021-06-05 17:36:56.000000000 -0700
+++ configure	2021-06-05 18:48:13.000000000 -0700
@@ -36350,7 +36350,7 @@
 #else
   int bug_possible = 0;
 #endif
-  if (! bug_possible)
+  if (1)
     return 0;
 
   cwd = getcwd (NULL, 0);

to abort running of the test.

I have no idea of this is a proper fix for this issue. I already tried looking around upstream for the Tiger RegNames issue, and I can't figure out where to even see the commit tree to m4, much less sort out how on Earth they would like you to go about asking a question.

And -- so far this only shows up for me on Leopard, so it's pretty hard to burn my limited cred on reporting Leopard bugs :>

If we want this teeny little fix as a patch in m4 to apply on Leopard (and less?) I'm happy to throw that 10 second patch into the port.

Last edited 18 months ago by kencu (Ken) (previous) (diff)

comment:6 Changed 18 months ago by kencu (Ken)

Description: modified (diff)

comment:7 Changed 18 months ago by leavenode

I'm currently building gcc7 on my third Tiger system. Fingers crossed m4 builds properly again this time. Losing it on Tiger would break a whole lot of stuff. Tiger is really the sweet spot for the old G4 machines.

comment:8 Changed 18 months ago by kencu (Ken)

don't give up! that little patch will fix it, if it keeps happening.

comment:9 in reply to:  8 Changed 18 months ago by leavenode

Thank you for your continued efforts to keep these lovely old machines relevant! I have basic *nix command line skills, but I am in no way any kind of a developer, so I rapidly end up way out of my depth trying to figure these issues.

Replying to kencu:

don't give up! that little patch will fix it, if it keeps happening.

comment:10 Changed 18 months ago by mjhsieh (Mengjuei Hsieh)

Temporary turning it off at configure file does unblock my m4 installation. Thanks a lot!

Last edited 18 months ago by mjhsieh (Mengjuei Hsieh) (previous) (diff)

comment:11 in reply to:  5 Changed 18 months ago by jmroot (Joshua Root)

Replying to kencu:

I have no idea of this is a proper fix for this issue. I already tried looking around upstream for the Tiger RegNames issue, and I can't figure out where to even see the commit tree to m4, much less sort out how on Earth they would like you to go about asking a question.

This would be the right branch of their repo: http://git.savannah.gnu.org/gitweb/?p=m4.git;a=tree;h=refs/heads/branch-1.4;hb=refs/heads/branch-1.4

However the m4 file in question comes from gnulib: https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/getcwd-abort-bug.m4;h=bd32de1b79683b8b4e3bc0694195115c46220709;hb=HEAD

So the place to discuss issues with that check would probably be here: https://lists.gnu.org/mailman/listinfo/bug-gnulib

comment:12 Changed 18 months ago by kencu (Ken)

It looks like this test came in years and years ago:

https://lists.gnu.org/archive/html/bug-gnulib/2011-04/msg00317.html

I would like to sort out why it is just showing up now, here, and apparently in no other software builds I have seen, after all these years before I ask any stupid questions upstream about it.

Is legacysupport getting involved here anywhere? We saw some kind of issue with recursive paths involving legacysupport in libarchive, and we never really sorted that out.

Last edited 18 months ago by kencu (Ken) (previous) (diff)

comment:13 Changed 18 months ago by kencu (Ken)

In 776b8ffb04c0a674a1b3fbce071de73c1e605a2d/macports-ports (master):

m4; work around error testing for PATH_MAX issue

disable this test, as it fails intermittently on some systems
seems to be only occurring on the oldest systems
proper upstream fix will be looked for

see: #62994

comment:14 Changed 18 months ago by kencu (Ken)

Last edited 18 months ago by kencu (Ken) (previous) (diff)

comment:15 Changed 14 months ago by mascguy (Christopher Nielsen)

Cc: mascguy added

comment:16 Changed 13 months ago by mascguy (Christopher Nielsen)

Cc: mascguy removed
Owner: set to mascguy
Status: newassigned

comment:17 Changed 11 months ago by kencu (Ken)

has duplicate #63603

comment:18 Changed 11 months ago by kencu (Ken)

Port: bison added

comment:19 Changed 11 months ago by kencu (Ken)

has duplicate #64373

comment:20 Changed 11 months ago by kencu (Ken)

Port: findutils added

comment:21 Changed 11 months ago by kencu (Ken)

Summary: m4 @1.4.19_1: fails on Leopard: /confdir-14B---: No space left on devicevarious ports fail to install on Leopard due to gnulib issue: /confdir-14B---: No space left on device

comment:22 Changed 11 months ago by kencu (Ken)

One interesting find from Peter was that changing the name of the test directory apparently fixed the problem:

"On PPC Leopard I patched configure that confdir-14B--- became confdir-14B---X – and the new bison version built."

comment:23 Changed 11 months ago by ballapete (Peter "Pete" Dyballa)

Cc: ballapete added

comment:24 Changed 11 months ago by ballapete (Peter "Pete" Dyballa)

In #64373 I emphasised that in MacPorts the configure script runs with elevated or root priviledges, while in my own environment it had normal priviledges. My configure script was invoked this way: time nice +11 env LANG=C PATH=/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin ./configure --prefix=/opt/local --disable-silent-rules --program-prefix=g CFLAGS="-pipe -Os -arch ppc" CPPFLAGS="-I/opt/local/include" LDFLAGS="-L/opt/local/lib -Wl,-headerpad_max_install_names -arch ppc" PKG_CONFIG_PATH=/opt/local/lib/pkgconfig:/opt/local/share/pkgconfig:/opt/local/lib/nspr/pkgconfig:/usr/X11R6/lib/pkgconfig:/usr/lib/pkgconfig CC=/usr/bin/gcc-4.2 INSTALL="/usr/bin/install -c" to mimic the MacPorts behaviour. I invoked it this evening like this:

time nice +11 sudo env LANG=C PATH=/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin ./configure --prefix=/opt/local --disable-silent-rules --program-prefix=g CFLAGS="-pipe -Os -arch ppc" CPPFLAGS="-I/opt/local/include" LDFLAGS="-L/opt/local/lib -Wl,-headerpad_max_install_names -arch ppc" PKG_CONFIG_PATH=/opt/local/lib/pkgconfig:/opt/local/share/pkgconfig:/opt/local/lib/nspr/pkgconfig:/usr/X11R6/lib/pkgconfig:/usr/lib/pkgconfig CC=/usr/bin/gcc-4.2 INSTALL="/usr/bin/install -c"

inserting a sudo before setting the process environment for configure. Configure's output in GNU Emacs' *compilation* buffer is the same as mine, and the config.log files also do not differ. So it must be something in MacPorts environment that hinders configure to find out immediately that getcwd aborts when 4k < cwd_length < 16k. And so it has to perform the problematic directory tree depth test.

Changed 11 months ago by ballapete (Peter "Pete" Dyballa)

Attachment: deepdir.c added

Test programme of Paul Eggert from gnulib support

comment:25 Changed 10 months ago by ballapete (Peter "Pete" Dyballa)

Yesterday I tried something new with bison on PPC Mac OS X 10.4.11, Tiger: I tried to "edit" the workdir before finishing the upgrade process (which had failed because of the depth of the directory tree). And I could not! Even rm on the command line could not handle this. I changed directory somewhere deep enough into the tree to be able to remove a whole branch (port reported what it could not remove, so I just needed to copy&paste into Terminal [because Emacs' shell is too limited in maximal length of command line]). Then I had to repeat the procedure, before port could finish upgrading.

So there are a few options to handle the problem manually…

comment:26 Changed 10 months ago by ryandesign (Ryan Schmidt)

Cc: barracuda156 added

Has duplicate #64492.

comment:27 in reply to:  5 Changed 10 months ago by barracuda156

Replying to kencu:

Yuk -- just saw this again on another system, and no combo of disabling parallel builds, etc, fixed it.

The issue is coming, it seems, from a test in this file m4/getcwd-abort-bug.m4 that makes it's way into the configure script. I didn't spend hours on it, but it looks like they are looking for some kind of bug in libc on certain versions of linux, that shows up when PATH_MAX < getpagesize ();.

To get around it, I did this:

Doesn't solve the issue for me on 10.5.8 when building m4 for ppc64.

comment:28 Changed 5 months ago by mascguy (Christopher Nielsen)

Cc: acjones8 added

comment:29 Changed 5 months ago by mascguy (Christopher Nielsen)

I'm finally able to reproduce this consistently, when building coreutils and findutils on 10.5.

So I'll try to take a look at this sometime soon.

Last edited 5 months ago by mascguy (Christopher Nielsen) (previous) (diff)

comment:30 Changed 5 months ago by mascguy (Christopher Nielsen)

Port: coreutils added

comment:31 Changed 5 months ago by kakuhen

I am here to report that coreutils @8.32_1 successfully installs on OS X 10.5.8 (ppc), but the most recent update to coreutils results in the repeated "confdir" paths until we surpass path length limits. Attached is a log of the build process for coreutils @9.1_0 on the system in question.

Changed 5 months ago by kakuhen

Attachment: main.log.gz added

Attempted build of coreutils @9.1_0 on ppc leopard

comment:32 in reply to:  31 ; Changed 4 months ago by mascguy (Christopher Nielsen)

Replying to kakuhen:

I am here to report that coreutils @8.32_1 successfully installs on OS X 10.5.8 (ppc), but the most recent update to coreutils results in the repeated "confdir" paths until we surpass path length limits. Attached is a log of the build process for coreutils @9.1_0 on the system in question.

As a test, you might want to try installing coreutils-devel. While the two are currently identical, the latter did build successfully for me on 10.5 PPC back a month ago. (That's probably just a fluke, particularly if all of this is caused by a race condition. But still worth a try!)

$ sudo port -f deactivate coreutils
$ sudo port -N install coreutils-devel

comment:33 in reply to:  32 Changed 4 months ago by ballapete (Peter "Pete" Dyballa)

Replying to mascguy:

Replying to kakuhen:

I just let MacPorts build the two packages. Both ports built, and both could be cleaned as well. The clue is the length of the path. My observation is that you can easily create an object that has a path name longer than allowed, longer than #defined in some C header file. When this happens then you cannot delete the last created directory, because it has now an illegal path length. What helps is to move (mv) some final part of the directory hierarchy into some other directory, / for example.

This behaviour depends on the length of the starting point, i.e. the length of the path name leading to the directory in which the port was outpaced and will be built. The value also depends on the site from where port fetches the sources or into which category it falls. You can check this length by invoking

port work <the port's name> | wc -c

The -devel variation adds six characters to the path name's length – this can make the difference. Other ways to make the port build and install is to edit the configure file and lengthen or shorten the directory name confdir-14B--- by adding or removing a minus sign or another character. The problem is that this to happen on more than one place since the inline C code of the test programmes does not use a shell variable set to the test directory name. And this can be done be letting port outpack the sources, kill the build process, edit the shell script, and let the build process start again. This the state of the build process was recorded in a DB (I presume), the build process just starts where it was interrupted and has the opportunity to succeed this time. If it fails again you'll have to clean, including some manual work, start again, kill, edit differently, continue – until installing succeeds.

comment:34 Changed 3 months ago by catap (Kirill A. Korinsky)

Cc: catap added

comment:35 Changed 3 months ago by catap (Kirill A. Korinsky)

Interesting, but I can't reproduce it via shell.

I can easy reproduce it as sudo port configure coreutils, but all attempts to reproduce it via sudo -u macports env ... ./configure ... fails. I mean that it works as expected, and removes folders.

I've also noticed that test whether getcwd handles long file names properly is always yes on coreutils-devel, without error and yes, but with shorter paths on coreutils with error.

Last edited 3 months ago by catap (Kirill A. Korinsky) (previous) (diff)

comment:36 Changed 7 weeks ago by amock (Alan Mock)

Cc: amock added

comment:37 Changed 5 weeks ago by khepler

Cc: khepler added

comment:38 Changed 5 weeks ago by cwoffenden (Carl Woffenden)

Cc: cwoffenden added

comment:39 in reply to:  32 Changed 4 weeks ago by barracuda156

Replying to mascguy:

As a test, you might want to try installing coreutils-devel. While the two are currently identical, the latter did build successfully for me on 10.5 PPC back a month ago.

We need to make dependency on coreutils path-style. Otherwise these errors happen:

sergey-fedorovs-power-mac-g5:~ svacchanda$ sudo port -v install armadillo
Warning: configured user/group macports does not exist, will build as root
--->  Computing dependencies for armadillo....
Error: Can't install coreutils because conflicting ports are active: coreutils-devel
Note: See TracTickets for help on using tickets.