Opened 3 years ago

Last modified 9 days 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), nathanpc (Nathan Campos), fhgwright (Fred Wright)
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 (6)

m4-leopard-fail.log (99.1 KB) - added by kencu (Ken) 3 years ago.
deepdir.c (6.4 KB) - added by ballapete (Peter "Pete" Dyballa) 2 years ago.
Test programme of Paul Eggert from gnulib support
main.log.gz (12.3 KB) - added by kakuhen 21 months ago.
Attempted build of coreutils @9.1_0 on ppc leopard
main.log (440.1 KB) - added by barracuda156 7 months ago.
Log of m4 build error on 10.5.8 from MacRoumors thread (patch has been applied, but build still failed) (not my log, I just repost here for convenience)
TestDirDepth.c (11.8 KB) - added by ballapete (Peter "Pete" Dyballa) 13 days ago.
TestDirDepth.c version from PPC Tiger, Mac OS X 10.4.11
TestDirDepth@Leopard.c (12.0 KB) - added by ballapete (Peter "Pete" Dyballa) 12 days ago.
TestDirDepth.c version from PPC Leopard, Mac OS X 10.5.8

Download all attachments as: .zip

Change History (101)

Changed 3 years ago by kencu (Ken)

Attachment: m4-leopard-fail.log added

comment:1 Changed 3 years ago by kencu (Ken)

Description: modified (diff)

comment:2 Changed 3 years 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 3 years ago by kencu (Ken)

Description: modified (diff)

comment:4 Changed 3 years 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 3 years 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 3 years ago by kencu (Ken) (previous) (diff)

comment:6 Changed 3 years ago by kencu (Ken)

Description: modified (diff)

comment:7 Changed 3 years 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 3 years 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 3 years 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 3 years ago by mjhsieh (Mengjuei Hsieh)

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

Last edited 3 years ago by mjhsieh (Mengjuei Hsieh) (previous) (diff)

comment:11 in reply to:  5 Changed 3 years 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 3 years 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 3 years ago by kencu (Ken) (previous) (diff)

comment:13 Changed 3 years 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 3 years ago by kencu (Ken)

Last edited 3 years ago by kencu (Ken) (previous) (diff)

comment:15 Changed 2 years ago by mascguy (Christopher Nielsen)

Cc: mascguy added

comment:16 Changed 2 years ago by mascguy (Christopher Nielsen)

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

comment:17 Changed 2 years ago by kencu (Ken)

has duplicate #63603

comment:18 Changed 2 years ago by kencu (Ken)

Port: bison added

comment:19 Changed 2 years ago by kencu (Ken)

has duplicate #64373

comment:20 Changed 2 years ago by kencu (Ken)

Port: findutils added

comment:21 Changed 2 years 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 2 years 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 2 years ago by ballapete (Peter "Pete" Dyballa)

Cc: ballapete added

comment:24 Changed 2 years 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 2 years ago by ballapete (Peter "Pete" Dyballa)

Attachment: deepdir.c added

Test programme of Paul Eggert from gnulib support

comment:25 Changed 2 years 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 2 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: barracuda156 added

Has duplicate #64492.

comment:27 in reply to:  5 Changed 2 years 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 21 months ago by mascguy (Christopher Nielsen)

Cc: acjones8 added

comment:29 Changed 21 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 21 months ago by mascguy (Christopher Nielsen) (previous) (diff)

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

Port: coreutils added

comment:31 Changed 21 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 21 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 21 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 21 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 19 months ago by catap (Kirill A. Korinsky)

Cc: catap added

comment:35 Changed 19 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 19 months ago by catap (Kirill A. Korinsky) (previous) (diff)

comment:36 Changed 18 months ago by amock (Alan Mock)

Cc: amock added

comment:37 Changed 17 months ago by khepler

Cc: khepler added

comment:38 Changed 17 months ago by cwoffenden (Carl Woffenden)

Cc: cwoffenden added

comment:39 in reply to:  32 Changed 17 months 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

comment:40 Changed 16 months ago by kencu (Ken)

In 96c9d4293aaa701ee42f292ddae87740c2b45ff6/macports-ports (master):

coreutils: fix build on Leopard

there are several tests run during configure, for issues that
do not occur on Darwin, that fail in an unusual fashion on Leopard.
This failure does not appear to occur on any other systems.

This patch avoids running these failing tests on Leopard.

see: #62994
closes: #66028

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

I just ran into this with gettext and a fix there was to add this to the configure args, which might be an easier workaround:

gl_cv_func_getcwd_path_max=yes

comment:42 in reply to:  41 Changed 11 months ago by barracuda156

Replying to kencu:

I just ran into this with gettext and a fix there was to add this to the configure args, which might be an easier workaround:

gl_cv_func_getcwd_path_max=yes

I have also ran into this with gettext now.

UPD. And yes, your fix works. Maybe commit it?

Last edited 11 months ago by barracuda156 (previous) (diff)

comment:43 Changed 11 months ago by catap (Kirill A. Korinsky)

In b58da074e58f314a0a760a21c28cfae4ad6aa03e/macports-ports (master):

coreutils{,-devel}, m4: avoid a patch to overstep max path bug

This is is much more stright forward way to overstep that bug that
makes supporting it much easy.

Half year ago I've tried to sent it to upstream, but hasn't been
successful, but still we may enjoy it as an easy workaround

See: #62994
See: https://lists.gnu.org/r/bug-gnulib/2022-09/msg00045.html

comment:44 in reply to:  43 ; Changed 11 months ago by barracuda156

Replying to catap:

In b58da074e58f314a0a760a21c28cfae4ad6aa03e/macports-ports (master):

coreutils{,-devel}, m4: avoid a patch to overstep max path bug

This is is much more stright forward way to overstep that bug that
makes supporting it much easy.

Half year ago I've tried to sent it to upstream, but hasn't been
successful, but still we may enjoy it as an easy workaround

See: #62994
See: https://lists.gnu.org/r/bug-gnulib/2022-09/msg00045.html

gettext also needs this.

comment:45 in reply to:  44 ; Changed 11 months ago by mascguy (Christopher Nielsen)

Replying to barracuda156:

gettext also needs this.

Yep, Kirill included fixes for gettext and ncurses too.

comment:46 in reply to:  45 Changed 11 months ago by barracuda156

Replying to mascguy:

Replying to barracuda156:

gettext also needs this.

Yep, Kirill included fixes for gettext and ncurses too.

Great!

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

anyone with Leopard: upstream gnulilb is hoping you will help them properly fix the test.

See this email for the test program they want you to work on fixing:

https://lists.gnu.org/archive/html/bug-gnulib/2022-01/msg00063.html

comment:48 Changed 11 months ago by mascguy (Christopher Nielsen)

I'm overdue to update the ports on my old MacbookPro running 10.5, so I'll test with the fixes. More to follow.

Sergey/Anyone, let us know if they help you as well!

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

the deepdir.c executable works perfectly normally on Leopard Intel at least...

so ain't that strange, then.

comment:50 in reply to:  47 Changed 11 months ago by catap (Kirill A. Korinsky)

Replying to kencu:

anyone with Leopard: upstream gnulilb is hoping you will help them properly fix the test.

See this email for the test program they want you to work on fixing:

https://lists.gnu.org/archive/html/bug-gnulib/2022-01/msg00063.html

I can't create a reproducer for that issue. Sometimes it works, sometimes it does. As far as I recall gettext and gettex-devel has different (!) behaviour with the same codebase.

Until someone can reproduce it I doubt that we may assist to testing and fixing the issue :(

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

I also confirm that multiple ports that exhibit this bug inside MacPorts build (gettext, m4) don't seem to have any problems configuring when I do them separately from MacPorts.

eg "m4" configures without any problem just on it's own, but fails inside a MacPorts build.

comment:52 in reply to:  51 Changed 11 months ago by catap (Kirill A. Korinsky)

Replying to kencu:

I also confirm that multiple ports that exhibit this bug inside MacPorts build (gettext, m4) don't seem to have any problems configuring when I do them separately from MacPorts.

eg "m4" configures without any problem just on it's own, but fails inside a MacPorts build.

I do have ansible playbook to easy update and install a setup with bootstrap macports :) So, I've repeated build from scratch on 10.5 more than once... and not each attempt it fails. It may works via MacPorts, may fail...

So, I have no idea how to hunt it down to fix.

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

mine fails every time in Macports, and never outside it.

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

could be sudo.

could be the deep build directory.

could be macports base.

probably not gnulib though :>

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

The question should be: Why is it possible to create a pathname that is too long to handle it afterwards, after creation? So that rm cannot handle it? Which is the final failure.

(Actually mv still can handle this 'out of limits' pathname somehow, for example move the last and deepest directory to /tmp and shorting the pathname by 14 or 15 characters that rm can remove the whole directory structure.)

In my tests, years ago, I modified the configure script to create subdirectories with shorter or longer names (by adding or removing HYPHEN-MINUS) and printing out the length of the pathname to be created. It could become longer than PATH_MAX = 1024.

The reason why it fails or not is that the directory structure starts with varying bias, because the working directory where configure starts from has variable length depending on the length of the utility's name and the length of the rsync server's name, the category of software, and possibly the starting point of MacPorts (it can be different from /opt or /opt/local, can't it?).

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

please make a reproducer where "m4" fails to configure on Leopard for you (the bare "m4", not the macports port m4).

I tried making a long long folder name and starting the configure inside there, and it still succeeded -- but perhaps there is some longer one that might fail.

comment:57 Changed 8 months ago by nathanpc (Nathan Campos)

Cc: nathanpc added

comment:58 Changed 8 months ago by nathanpc (Nathan Campos)

Just tested on Leopard (PowerPC) and the patch shared in comment:5 fixed the issue and got the m4 package to build with no issues. Maybe the patch should be included in the port for Leopard?

comment:59 Changed 8 months ago by ryandesign (Ryan Carsten Schmidt)

Sure, but it potentially affects every port whose configure script was built using gnulib, which is probably thousands of ports.

comment:60 Changed 8 months ago by and3r00 (Andrew)

The instructions for patching ports in macports is lacking. No option to install locally. No option to point port to install an older or different version. No information on how to manually install a port in conjunction and register into Macports. I was able to build the port manually with comment 5's solution, to find that the instructions for applying the diff not working. I need more details from Macports on how to apply diff patches to their ports.

I also find it amusing that instead of fixing the port and closing the issue, the have left this issue open for years.

comment:61 in reply to:  59 Changed 7 months ago by barracuda156

Replying to ryandesign:

Sure, but it potentially affects every port whose configure script was built using gnulib, which is probably thousands of ports.

Well, people complain that m4 is broken on 10.5.8, and I can confirm it indeed is:

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

Macports is essentially unusable without manual hackery on Leopard at the moment. (As I recall, the same applied to Rosetta builds, so 10.6 with build_arch ppc too.)

Last edited 7 months ago by barracuda156 (previous) (diff)

comment:62 Changed 7 months ago by kencu (Ken)

unless you try building m4 manually, outside of MacPorts, in which case m4 builds just fine every time I do it on Leopard.

upstream had some suggestions about how to look into this, but I'm pretty sure nobody has taken them up on it:

https://lists.gnu.org/archive/html/bug-gnulib/2022-01/msg00063.html

comment:63 in reply to:  62 Changed 7 months ago by catap (Kirill A. Korinsky)

Replying to kencu:

upstream had some suggestions about how to look into this, but I'm pretty sure nobody has taken them up on it:

https://lists.gnu.org/archive/html/bug-gnulib/2022-01/msg00063.html

I've spent a few hours on that but can't create a simple reproducer. It seems that the issue between path length and (d)word size; it also explains why -devel or non-devel port works, when another one doesn't.

comment:64 Changed 7 months ago by barracuda156

BTW, reportedly, the hack mentioned above stopped working on 10.5.8 – or at least may fail on some configurations.

Changed 7 months ago by barracuda156

Attachment: main.log added

Log of m4 build error on 10.5.8 from MacRoumors thread (patch has been applied, but build still failed) (not my log, I just repost here for convenience)

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

another dup #69084

comment:66 in reply to:  65 Changed 6 weeks ago by barracuda156

Replying to kencu:

another dup #69084

gettext-tools-libs also fails likewise. Confirmed on 10.5.8 i386.

So in effect we have 10.5.8 [still] completely unusable. Basic ports are broken, so literally nothing can be built.

Last edited 6 weeks ago by barracuda156 (previous) (diff)

comment:67 Changed 6 weeks ago by kencu (Ken)

I have hundreds and hundreds of ports built on my 10.5.8 PPC system.

Finding a fix for this is will be palatable to everyone is hard -- however, fixing it yourself is but a few minutes work.

Let me see if I can get a patch pushed through. Yes -- it won't please everyone.

Last edited 6 weeks ago by kencu (Ken) (previous) (diff)

comment:68 Changed 5 weeks ago by fhgwright (Fred Wright)

Cc: fhgwright added

comment:69 Changed 2 weeks ago by ilovecrts

Hello everyone,

I am very much a novice programmer and definitely a newbie when it comes to Macports. Please forgive me if I sound simple and naive. :)

I was directed here by kencu after my attempts of installing m4 with the command "sudo port install m4" failed.

I think I found the "configure" file noted by kencu in comment #5.

Mine is located in :

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_m4/m4/work/m4-1.4.19

I edited the file with "sudo nano configure" and searched for the string "bug_possible".

I commented out the original if statement and added in the suggested test for TRUE.

#endif

/* if (! bug_possible) */

if (1)

return 0;

After saving the file I reran the command "sudo port install m4". Unfortunately, I ended up with the same error.

What am I doing incorrectly?

Thank you! :)

P.S. I don't understand why the spacing and formatting of my transcribed code looks so weird here.

P.S.S. I am running Leopard 10.5.8 on a 1.25 GHz eMac.

Last edited 2 weeks ago by ilovecrts (previous) (diff)

comment:70 Changed 2 weeks ago by ilovecrts

I think I broke something here.

I ran "sudo port clean m4" thinking this would help. Instead, it made it worse. Now when I run "sudo port install m4" I get the following output.

$ sudo port clean m4 -all

---> Cleaning m4 Error: error deleting "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_m4/m4/work/m4-1.4.19/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---": file name too long

$ sudo port install m4

Error: Unable to execute port m4: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_m4/m4/work/m4-1.4.19/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---: file name too long $

What is the remedy?

Thank you! :)

Last edited 2 weeks ago by ilovecrts (previous) (diff)

comment:71 Changed 2 weeks ago by kencu (Ken)

once that directory exists, it is unfortunately very hard to get rid of it.

I believe I did something like this:

sudo rm -rf /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_m4/m4

about 15 times, and the directory finally was deleted.

clearly, this is a messy deal.

comment:72 in reply to:  71 Changed 2 weeks ago by ballapete (Peter "Pete" Dyballa)

Replying to kencu:

about 15 times, and the directory finally was deleted.

Try to mv a part of that long directory tree to /tmp or ~ and remove the remainder and the moved tree branch with one command!

comment:73 Changed 2 weeks ago by ballapete (Peter "Pete" Dyballa)

One way to successfully install a port would be to just build (and test) it. This will give the opportunity to remove some part of the confdir-14B--- directory tree manually and then invoke port upgrade. port build will use the up-to-date Portfile and source, in the upgrade phase port will have knowledge that it already built before and now can install the up-to-date package.

comment:74 in reply to:  67 Changed 2 weeks ago by barracuda156

Replying to kencu:

I have hundreds and hundreds of ports built on my 10.5.8 PPC system.

Finding a fix for this is will be palatable to everyone is hard -- however, fixing it yourself is but a few minutes work.

Well, I obviously have m4 and gettext building and working on 10.6 (ppc / i386) and perhaps 10.5 (unless something got broken further very recently), but what is a few minutes work for us, may be a stopper for someone else. I was in that position myself at some point, and if not for your detailed instructions back then, would have likely given up.

IMO to keep support for older systems alive we need to have basic stuff working “out of the box”, so that we do not lose potentially interested to contribute people.

Let me see if I can get a patch pushed through. Yes -- it won't please everyone.

Ken, if you mean that you are not gonna apply it for 10.6 Rosetta and unsupported native ppc, that is still better than having everything broken. Most people arguably use 10.5.8 on PowerPC, so that is the major thing to fix. I can survive carrying an out-of-tree patch for 10.6 ppc here, it does not add much of a maintenance burden. (Strictly speaking, the bug has nothing to do with PowerPC, but rather conditional on SDK and/or Xcode tools version. Same problem happens on 10A190 i386 – natively run on CoreDuo.)

  1. S. On a side note, maybe it is easier to just update Unix tools for Leopard (and identical procedure will fix pre-released 10.6 too)?

This perhaps cannot be done via Macports master, but it can be distributed via a pkg update (as long as licenses permit that). What do you think?

Presumably it can fix a lot of silly errors.

comment:75 Changed 2 weeks ago by kencu (Ken)

what I meant was that “hack fixes” like what this is going to need can get heavily criticized, so frankly I prefer others to do them and take the heat.

But three years on and nobody did it yet….

I had hoped somebody might be interested enough to work with upstream on the proper fix, so I have been waiting for that to happen.

But it appears nobody is sufficiently interested to do that.

comment:76 in reply to:  75 Changed 2 weeks ago by ballapete (Peter "Pete" Dyballa)

Replying to kencu:

what I meant was that “hack fixes” like what this is going to need can get heavily criticized, so frankly I prefer others to do them and take the heat.

But it appears nobody is sufficiently interested to do that.

Why not working around it with mv and rm -rf? Because: Are the GNU folks interested in supporting a dead OS? There is another problem with GNUlib, probably connected to 64-bit data and functions, which does not show any progress…

comment:77 Changed 2 weeks ago by kencu (Ken)

gnulib has been responsive, but they can't reproduce the issue, so need somebody to step up.

comment:78 in reply to:  77 ; Changed 2 weeks ago by ballapete (Peter "Pete" Dyballa)

Replying to kencu:

gnulib has been responsive, but they can't reproduce the issue, so need somebody to step up.

Is this ticket somewhere recorded?

If nobody is going to open a ticket for this directory tree issue, I'll try to… (in a few hours, first I'll have to find out which GNU software has this issue – and it's dinner time here!)

comment:79 in reply to:  78 Changed 2 weeks ago by kencu (Ken)

Replying to ballapete:

Replying to kencu:

gnulib has been responsive, but they can't reproduce the issue, so need somebody to step up.

Is this ticket somewhere recorded?

Look above, the reference is up there, comment:62

(You opened the discussion with upstream :) ).

Last edited 13 days ago by kencu (Ken) (previous) (diff)

comment:80 Changed 2 weeks ago by ballapete (Peter "Pete" Dyballa)

These seem to be all the reported MacPorts tickets:

#69084, m4 1.4.19, PPC Leopard -> #62994
#67913, m4 1.4.19, PPC Leopard -> #62994
#67882, m4 1.4.19, PPC Leopard -> #62994, with configure run
#64492, m4 1.4.19, PPC Leopard
#63059, m4 1.4.19, PPC Leopard -> #62994
#64373, findutils 4.7.0, PPC Leopard -> #62994
#58927, findutils 4.7.0, PPC Leopard -> #50567
#50567, findutils 4.6.0, PPC Leopard -> #62994 -> #62994
#63603, bison 3.8.2, PPC Leopard + PPC Tiger -> #62994 + some observations
#62994, coreutils 9.1
#28654, gzip-1.4, ?, from 2011 (incorrectly set as duplicate of #28496)

Obviously it's a common test procedure, part of this gnulib.

comment:81 in reply to:  71 Changed 2 weeks ago by ilovecrts

Replying to kencu:

once that directory exists, it is unfortunately very hard to get rid of it.

I believe I did something like this:

sudo rm -rf /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_m4/m4

about 15 times, and the directory finally was deleted.

clearly, this is a messy deal.

I was successful in deleting this folder and the subfolders underneath by using the Finder! It didn't even dawn on me to try that first! :)

I'd like to try the "hack" again.

I ran "sudo port install m4" and the process bonked out as expected.

Is there a simplified, step-by-step instructions I can follow to get m4 to build? I tried editing the configure file in comment #5 above and rerunning "sudo port install m4", but that didn't work.

Thanks for everyone's patience with me here!

comment:82 Changed 2 weeks ago by ballapete (Peter "Pete" Dyballa)

Paul Eggert seems to have the solution: https://lists.gnu.org/archive/html/bug-gnulib/2022-01/msg00085.html. I fail to understand…

The C test programme is:

 1	  if (1)
 2	    {
 3	      static char const dir_name[] = "confdir-14B---";
 4	      size_t desired_depth = ((TARGET_LEN - 1 - initial_cwd_len)
 5	                              / sizeof dir_name);
 6	      size_t d;
 7	      for (d = 0; d < desired_depth; d++)
 8	        {
 9	          if (mkdir (dir_name, S_IRWXU) < 0 || chdir (dir_name) < 0)
10	            {
11	              if (! (errno == ERANGE || errno == ENAMETOOLONG
12	                     || errno == ENOENT))
13	                fail = 3; /* Unable to construct deep hierarchy.  */
14	              break;
15	            }
16	        }         /* end of for loop */
17	
18	      /* If libc has the bug in question, this invocation of getcwd
19	         results in a failed assertion.  */
20	      cwd = getcwd (NULL, 0);
21	      if (cwd == NULL)
22	        fail = 4; /* getcwd didn't assert, but it failed for a long name
23	                     where the answer could have been learned.  */
24	      free (cwd);
25	
26	      /* Call rmdir first, in case the above chdir failed.  */
27	      rmdir (dir_name);
28	      while (0 < d--)
29	        {
30	          if (chdir ("..") < 0)
31	            {
32	              fail = 5;
33	              break;
34	            }
35	          rmdir (dir_name);
36	        }         /* end of while loop */
37	    }

On line #9 it first creates the subdirectory and, when successful, changes into it. If it had no success it breaks out of the for loop.

On line #20 a pointer to the pathname of the last directory created is stored in array cwd. If pathname could not be determined, the NULL pointer is returned. This is tested in the next two lines and the storage for pathname gets cleared (free'd), line #24.

On line #27 a possibly not existing sub-directory ("confdir-14B---") is removed. Can this work? Does it provoke the report "…: No space left on device"?

On line #28 starts a while loop in which the current working directory is changed to the parent directory ("..") and if successful the now sub-directory "confdir-14B---" is removed (line #35), otherwise an error is raised and the while loop is quit at one (line #30–33).

Is my interpretation correct? Which is the test Paul Eggert sees but not me?

IMO rmdir() seems to fail. So why not leaving out (patching away) the line #26–36 and doing the clean-up in two steps (mv branch to X, then rm -rf remaining confdir-14B--- and X) with reliable system utilities? There also seems to be difference in the behaviour of rmdir(): Inside the MacPorts environment it tends to fail while in some user's environment it seems to succeed?

I cannot see any reason for a new bug report…

comment:83 Changed 13 days ago by ballapete (Peter "Pete" Dyballa)

I think I understand now what Paul Eggert means when he uses the term "test": It's exactly this little test programme! But then his last sentence "If so, perhaps we should alter the test program so that it can be run in such a way that it *only* cleans up after itself, and we use that for cleanup since macOS 'rm' isn't up to the task." does not make any sense to me…

If it does not create the deep directory hierarchy what is there to clean up?

The test is "whether getcwd succeeds when 4k < cwd_length < 16k". I think we know that on Tiger and Leopard (and maybe more) "cwd_length" is restricted to 1K, #defined in macros like PATH_MAX or MAXPATHLEN or FILENAME_MAX with the latter two being derived from PATH_MAX. So why not leave out that superfluous test on these systems? Besides, it seems to be related to an "AIX bug"…

comment:84 Changed 13 days ago by ballapete (Peter "Pete" Dyballa)

In m4 the configure script removes all scrap from the test on lines #36417 and #36418. Just before line #36417 one can insert a line like

cp -v conftest.c /var/tmp/TestDirDepth.c

to safe the test programme for further use in order to examine some aspects of Mac OS X. I did that on Mac OS X 10.4.11, PPC Tiger. It was compiled this way (recorded in config.log; search for the text string "4k"):

/opt/local/bin/gcc-apple-4.2 -std=gnu99 -o conftest -pipe -Os -arch ppc -I/opt/local/include -L/opt/local/lib -Wl,-headerpad_max_install_names -arch ppc conftest.c

Now C programmers could extend the code, make the programme output which is its current working directory in the for loop and how long the pathname has grown, make it output what it tries to remove from where before it enters the while loop. And reporting the return value of this first rmdir() call. By running it from a directory whose name is made longer by one character (or digit) every time before launching it, we can make it fail at some instance, i.e. leave that confdir-14B--- directory tree because it has become too long for rm (or rmdir()?) to remove the whole tree. It might work better by adding a routine that reads that subdirectory name from command line, or that creates in another loop automatically new temporary names with growing length to accelerate the tests, to fail without human interference.

The PPC Leopard, Mac OS X 10.5.8 version will be delivered some time in the near future, when upgrading MacPorts on Tiger will have finished (and also reporting new bugs, npth 1.7).

Changed 13 days ago by ballapete (Peter "Pete" Dyballa)

Attachment: TestDirDepth.c added

TestDirDepth.c version from PPC Tiger, Mac OS X 10.4.11

comment:85 Changed 12 days ago by ballapete (Peter "Pete" Dyballa)

On PPC Leopard, Mac OS X 10.5.8 the test programme is compiled slightly differently:

/usr/bin/gcc-4.2 -std=gnu99 -o conftest -pipe -Os -arch ppc -I/opt/local/include -L/opt/local/lib -Wl,-headerpad_max_install_names -arch ppc conftest.c 

It's the original Apple compiler that is used. Obviously Tiger is a bit harder to maintain…

The test code is of course the same, differences appear in the stack of #defines that describe the system to be tested. Leopard for example knows how to spawn()

Changed 12 days ago by ballapete (Peter "Pete" Dyballa)

Attachment: TestDirDepth@Leopard.c added

TestDirDepth.c version from PPC Leopard, Mac OS X 10.5.8

comment:86 Changed 11 days ago by ballapete (Peter "Pete" Dyballa)

Today I restarted my two years old bug report and asked Paul Eggert whether this directory depth test could be put inside a clause that only becomes true on AIX since it seems to be an AIX problem.

comment:87 Changed 11 days ago by ballapete (Peter "Pete" Dyballa)

/opt/local/bin/grm from coreutils seems to be able to remove the too deep tree…

comment:88 Changed 11 days ago by ballapete (Peter "Pete" Dyballa)

I am not an experienced C programmer so I may be wrong here. Adding to the test programme some lines to output diagnostics into a file it seems the break; instruction of the (first) for loop that builds up the directory tree is never reached. It just happens a crash before. And so the (second) while loop that removes the tree cannot perform, the deep tree is left over.

comment:89 in reply to:  88 Changed 11 days ago by ballapete (Peter "Pete" Dyballa)

Replying to ballapete:

I am not an experienced C programmer so I may be wrong here.

Yes, I was! I have to correct myself! It's my code that I added to the for loop and is executed when subdirectory creation succeeds, now out-commented:

//        else
//          {
//            cwd = getcwd (NULL, 0);
//            fprintf (f, "Level %3d, %4d chars long in %s\n", -d - 1, strlen (cwd), cwd);
//          }

Obviously fprintf() has a problem printing strings of > 3.5 K length to a file.

comment:90 Changed 10 days ago by ballapete (Peter "Pete" Dyballa)

We're close to solving this Gnulib problem: https://lists.gnu.org/archive/html/bug-gnulib/2024-03/msg00208.html. Right now I am "experimenting" on Leopard, where ktrace/kdump do not exist anymore. And I also could not reproduce yet the circumstances (but I have a confdir-14B--- tree that cannot be removed with /bin/rm). Finally I'll be quite busy with other things today, so we need volontaires with this tree or the ability to create it easily with MacPorts – on Tiger! Here ktrace/kdump do still exist.

First you need to become root– the sudo command and its usage is probably known to you all.
Then you'll have to change directory to where the confdir-14B--- tree is. port work m4 will return something like /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_m4/m4/work, adding /m4-1.4.19 to the previous value is where confdir-14B--- tree lies around.
So cd there, still as super-user root, and run, as Paul Eggert writes:

export LC_ALL=C
ktrace rm -rf confdir-14B---
kdump

From the list archive you can easily answer Paul Eggert. With some kindness you could CC me (Peter_Dyballa at Web.DE), Ryan Schmidt (ryandesign at macports.org), and particularly bug-gnulib at gnu.org!

And I'll see whether I can handle dtrace/dtruss

comment:91 Changed 9 days ago by ballapete (Peter "Pete" Dyballa)

Paul Eggert sees nothing he could do: https://lists.gnu.org/archive/html/bug-gnulib/2024-03/msg00208.html. He states that Apple's /bin/rm should be banned because too buggy. What he finally suggests, maybe because the troublesome test programme does not produce much useful information, is:

./configure gl_cv_func_getcwd_succeeds_beyond_4k=no

Good enough for all GNU utilities/ports?

comment:92 Changed 9 days ago by ballapete (Peter "Pete" Dyballa)

It would be much appreciated when those with problems and reading this ticket would test the solution and submit their experience. sudo port edit <package name> opens the package's Portfile for editing. There you'll certainly find a line starting with configure.args. Amongst the present arguments you can add this new one gl_cv_func_getcwd_succeeds_beyond_4k=no \ before the last line of this block (identified by a line not ending with a backslash). Don't forget to save the change to Portfile! And try to build.

comment:93 Changed 9 days ago by ballapete (Peter "Pete" Dyballa)

Another option would be to extend Portfile a bit: If configure phase fails (more reasons for that are possible) it patches the configure script so that the directory name confdir-14B--- becomes confdir--15B--- or such and restarts. Permutations of this name until it works might follow. Of course before port tries a "new trick" it can check that this directory exists.

Last edited 9 days ago by ballapete (Peter "Pete" Dyballa) (previous) (diff)

comment:94 Changed 9 days ago by kencu (Ken)

Good work upstream.

Current speculation is this test brings out a bug in “rm” that shows up intermittently, and must have been fixed by 10.6+.

No fix for gnulib is likely, but workarounds are to use “grm” from coreutils, or set gl_cv_func_getcwd_succeeds_beyond_4k=no in ports that use gnulib, at least on older OS versions.

If that latter thing pans out and works, that would be a maintainable option. We should test that.

Thanks, Peter

Last edited 9 days ago by kencu (Ken) (previous) (diff)

comment:95 in reply to:  94 Changed 9 days ago by ballapete (Peter "Pete" Dyballa)

Replying to kencu:

Thanks, Peter

Here possibility to save some energy and one character, the final "r".

Note: See TracTickets for help on using tickets.