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

[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

[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.

[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 :>

[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.

[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.

[kencu (Ken)]

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

[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.

[mjhsieh (Mengjuei Hsieh)]

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

[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

[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, 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.

[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

[kencu (Ken)]

I'm going to call this report possibly related:

​https://debbugs.gnu.org/cgi/bugreport.cgi?bug=13516

it describes runaway recursion in rpl_getcwd on older darwin systems, and led to this:

​https://github.com/coreutils/gnulib/commit/ca369c8d661a10d8a0ae3d712e7dfa91664921f1#diff-c69eaca7e6f1ba35514471af9dd4290ac86c095dff9a5060f9f41963ad1f2177

[kencu (Ken)]

has duplicate #63603

[kencu (Ken)]

has duplicate #64373

[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."

[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.

[ballapete (Peter "Pete" Dyballa)]

Test programme of Paul Eggert from gnulib support

[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…

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #64492.

[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.

[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.

[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.

[kakuhen]

Attempted build of coreutils @9.1_0 on ppc leopard

[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

[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.

[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.

[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

[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

[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

[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?

[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

[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.

[mascguy (Christopher Nielsen)]

Replying to barracuda156:

gettext also needs this.

Yep, Kirill included fixes for gettext and ncurses too.

[barracuda156]

Replying to mascguy:

Replying to barracuda156:

gettext also needs this.

Yep, Kirill included fixes for gettext and ncurses too.

Great!

[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

[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!

[kencu (Ken)]

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

so ain't that strange, then.

[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 :(

[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.

[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.

[kencu (Ken)]

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

[kencu (Ken)]

could be sudo.

could be the deep build directory.

could be macports base.

probably not gnulib though :>

[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?).

[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.

[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?

[ryandesign (Ryan Carsten Schmidt)]

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

[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.

[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.)

[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

[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.

[barracuda156]

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

[barracuda156]

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)

[kencu (Ken)]

another dup #69084

[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.

[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.

[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.

[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! :)

[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.

[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!

[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.

[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.)

16. 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.

[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.

[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…

[kencu (Ken)]

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

[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!)

[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 :) ).

[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.

[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!

[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…

[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"…

[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).

[ballapete (Peter "Pete" Dyballa)]

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

[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()…

[ballapete (Peter "Pete" Dyballa)]

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

[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.

[ballapete (Peter "Pete" Dyballa)]

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

[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.

[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.

[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…

[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?

[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.

[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.

[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

[ballapete (Peter "Pete" Dyballa)]

Replying to kencu:

Thanks, Peter

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

[itaboss (Dan Boss)]

Replying to ballapete:

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.

Many thanks Pete, it worked for me on 10.5.8.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ilovecrts:

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

Everyone would benefit from reading WikiFormatting and TracLinks.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ballapete:

Paul Eggert […] states that Apple's /bin/rm should be banned because too buggy.

All I can say to that is that Leopard's rm was sufficiently bug-free to pass POSIX certification and to be shipped to millions of customers for years without a problem having been noticed. So whatever alleged bug is being triggered here is due to unusual usage by gnulib and it would be reasonable for gnulib to work around that. But it's clear the developer of gnulib has no interest in helping us with this. If we could find the problem in the gnulib code and develop a simple fix, I suspect Paul might accept it but that we're on our own with figuring it out.

[ballapete (Peter "Pete" Dyballa)]

Me, I do not understand what sense it might make to create paths or a directory hierarchy beyond the system's limit. What does the test find out? That mkdir is more powerful than rm? (Because rm cannot delete what mkdir created?) That this system's limits are as soft as butter? (And might be true for other aspects?)

[barracuda156]

Someone should really fix m4 port, otherwise nobody is able to build literally anything on Leopard.

[ballapete (Peter "Pete" Dyballa)]

Replying to barracuda156:

What are you missing from my how-to? (BTW, without a working py-bootstrap-modules I cannot upgrade 20 or 30 ports, plus TeX Live 2024.)

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #69701.

[ryandesign (Ryan Carsten Schmidt)]

So, bison still needs the fix and doesn't have it; the fix in the m4 port doesn't work because configure.args get set afterwards, overwriting the fix; and in the ports where we use a fix we're using gl_cv_func_getcwd_path_max=yes while the developer suggests using gl_cv_func_getcwd_succeeds_beyond_4k=no instead. And we're copying the fix into each affected portfile rather than handling it centrally.

I've tried to deal with all these issues here: ​https://github.com/macports/macports-ports/pull/23426

If more ports are discovered that need the fix, it should be as simple as adding PortGroup gnulib 1.0 to them.

[ryandesign (Ryan Carsten Schmidt)]

I don't see any evidence that ncurses uses gnulib so I've removed the workaround from that port.

[programmingkidx]

@ryandesign I tried to test out your pull request but it didn't work for me. Maybe it was the way I tried to copy it. I cloned your repo: ​https://github.com/ryandesign/macports-ports/tree/gnulib. Checked out the gnulib branch. Then copied the the 7 files you changed from the repo to my corresponding macports folders. Is there any easier way to do this? When I was done with the copying the files I ran "sudo port install m4". I saw the same "confdir-14B--/" text repeated still. Does m4 install for you?

[ryandesign (Ryan Carsten Schmidt)]

I have not tested on an older system.

You can try changing gl_cv_func_getcwd_succeeds_beyond_4k=no back to gl_cv_func_getcwd_path_max=yes since that's what we were successfully using before.

[barracuda156]

Replying to ryandesign:

I have not tested on an older system.

You can try changing gl_cv_func_getcwd_succeeds_beyond_4k=no back to gl_cv_func_getcwd_path_max=yes since that's what we were successfully using before.

Ah, let me try both. Will let you know soon.

[ballapete (Peter "Pete" Dyballa)]

Replying to programmingkidx:

When I was done with the copying the files I ran "sudo port install m4". I saw the same "confdir-14B--/" text repeated still.

This should not happen with the additional configure argument gl_cv_func_getcwd_succeeds_beyond_4k=no. It simply avoids this directory check. Does your version of Portfile contain this additional configure argument?

[barracuda156]

Looks like Ryan's fix works fine.

[programmingkidx]

@ballapete My Portfile does not contain the additional configure argument. I did try adding it but it didn't fix the problem. M4 still fails to install with the same "confdir-14B--/" text repeated.

I think this is what you wanted me to do:

configure.args  --disable-silent-rules \
                --program-prefix=g \
                --with-packager=MacPorts \
                --with-packager-version="revision $revision" \
                --with-packager-bug-reports=https://trac.macports.org/wiki/Tickets \
                ac_cv_libsigsegv=no \
		gl_cv_func_getcwd_succeeds_beyond_4k=no

[programmingkidx]

@barracuda156 Are you testing on Mac OS 10.5? x86 or PowerPC? How did you apply Ryan's patches?

[programmingkidx]

@ryandesign I tried changing gl_cv_func_getcwd_succeeds_beyond_4k=no back to gl_cv_func_getcwd_path_max=yes. I still saw the same repeated error string when running "sudo port install m4".

[ryandesign (Ryan Carsten Schmidt)]

Replying to programmingkidx:

My Portfile does not contain the additional configure argument.

The Portfile isn't supposed to contain the argument anymore. That's the point of my PR: to centralize the fixes into the gnulib portgroup.

Please attach the main.log file so that we can investigate why it failed for you.

[programmingkidx]

Unfortunately there doesn't appear to be a main.log file made.

[barracuda156]

Replying to programmingkidx:

@barracuda156 Are you testing on Mac OS 10.5? x86 or PowerPC? How did you apply Ryan's patches?

10.5.8 ppc64, I just checked out to GH branch and copied PG and portfiles.

[kencu (Ken)]

testing out PRs that include changes to PortGroups can be tricky, because things do not always work the way you might expect them to work.

the only really certain way to do it is to use a github checkout of the ports tree, make that the primary default source for ports, and then checkout the PR into that github checkout of the ports tree and run a portindex in that folder first.

and if none of the makes any sense to you .... well ... just wait for the commit to roll out and see how it works for you, I would say.

[ballapete (Peter "Pete" Dyballa)]

Replying to ryandesign:

Replying to programmingkidx:

My Portfile does not contain the additional configure argument.

The Portfile isn't supposed to contain the argument anymore. That's the point of my PR: to centralize the fixes into the gnulib portgroup.

Sorry, my question should have been, whether this additional configure argument appears in the log…

[ballapete (Peter "Pete" Dyballa)]

Replying to programmingkidx:

Unfortunately there doesn't appear to be a main.log file made.

The port utility saves the status of what it performed previously. This way it can continue work when it was interrupted before. This status file needs to be deleted together with the already outpacked sources – by simple port clean <port name>. This also removes the log file. And it particularly makes port re-read how to handle the sources, applying for example new rules, when invoked newly. Without cleaning port will remain in the old, stale state from first try.

[programmingkidx]

Well something happened and now M4 installed. Good work everyone.

[ryandesign (Ryan Carsten Schmidt)]

In a4b8f7a9f922ee4909d0957e1aec5299a0f3598d/macports-ports (master):

gnulib: New portgroup for gnulib workaround

Centralize the gnulib configure test override for Mac OS X Leopard and
older into a portgroup and change it from gl_cv_func_getcwd_path_max=yes
to gl_cv_func_getcwd_succeeds_beyond_4k=no based on the suggestion of
the gnulib developer.

See: ​https://lists.gnu.org/archive/html/bug-gnulib/2024-03/msg00250.html
See: #62994

[ryandesign (Ryan Carsten Schmidt)]

In 59a47c0e85db4eb9f759f43bb8f9ba62f647642e/macports-ports (master):

bison: Use gnulib workaround

See: #62994

[ryandesign (Ryan Carsten Schmidt)]

In ddf6ec78899378d8aeb1cd7b1c104311bdaecf36/macports-ports (master):

coreutils*: Use centralized gnulib workaround

See: #62994

[ryandesign (Ryan Carsten Schmidt)]

In 4f0b4ee346f8752f965a50cc9a1c4b083bf5cdaf/macports-ports (master):

m4: Use centralized gnulib workaround

See: #62994

[ryandesign (Ryan Carsten Schmidt)]

In 2a7eace4afd6b67e06e0bd6a65d5e7ef0e18de1e/macports-ports (master):

gettext: Use centralized gnulib workaround

See: #62994

[ryandesign (Ryan Carsten Schmidt)]

In d17f5954b8345f53e23e6217bf489c9b289adecf/macports-ports (master):

ncurses: Remove gnulib workaround

ncurses does not use gnulib.

See: #62994

[rmottola (Riccardo)]

Replying to ryandesign:

In ddf6ec78899378d8aeb1cd7b1c104311bdaecf36/macports-ports (master):

coreutils*: Use centralized gnulib workaround

See: #62994

I don't this centralized workaround, but as of today the coreutils bug hit me again on 10.5 x96-64

the directory name is different, but I suppose the bug is the same:

config.status: creating po/Makefile
rm: confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3: No space left on device

[rmottola (Riccardo)]

Same issue for coreutils on 10.5 PPC

[kencu (Ken)]

so that directory shouldn't have even been created -- which leads me to ponder that it might be left behind / left over from some previous attempt to build this.

can you sudo port clean coreutils

then go into the directory and make sure eveything is gone:

cd `port dir coreutils`
ls

and if you still see a work directory in there, remove it using "grm" which was noted above to be capable of removing this deep directory.

now -- catch 22 -- you can't use "grm" unless you have installed coreutils already .... so what I did was

sudo rm -rf work

about 10 times and it seemed to finally get rid of the directory...

[fhgwright (Fred Wright)]

Replying to kencu:

so that directory shouldn't have even been created -- which leads me to ponder that it might be left behind / left over from some previous attempt to build this.

can you sudo port clean coreutils

then go into the directory and make sure eveything is gone:

cd `port dir coreutils`
ls

and if you still see a work directory in there, remove it using "grm" which was noted above to be capable of removing this deep directory.

Using port dir coreutils only works if the work directory is under the port directory, which AFAIK is only true if one used the "omitted portname kludge" to attempt the build in the first place.

now -- catch 22 -- you can't use "grm" unless you have installed coreutils already .... so what I did was

sudo rm -rf work

about 10 times and it seemed to finally get rid of the directory...

What I found works is:

cd $(port work <portname>)
sudo mv .../<some deeper directory> .
sudo rm -rf <some deeper directory>
cd -
sudo port clean <portname>

I.e., it looks like a single mv of a subtree to a shallower depth is sufficient to make rm -rf work. The explicit rm -rf might not even be necessary, since the mv alone might be sufficient to make port clean work.

Note that if you haven't been consistent about whether you're using the "omitted portname kludge" or not, then you may need to do the above twice, with and without the kludge.

[kencu (Ken)]

Replying to fhgwright:

Using port dir coreutils only works if the work directory is under the port directory

A symlink to the work directory is always under the port directory:

% sudo port extract kdelibs4
% cd `port dir kdelibs4`

% ls
Portfile	files		work

and all these years in, I often just cd into work from there when I am working on a port, and cd .. back up again.

But if you "rm -rf" the work directory from there, it indeed removes the symlink. You indeed must cd into the work directory to get at the crappy deep directory.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #69770.

[ryandesign (Ryan Carsten Schmidt)]

The log in #69770 shows that the configure argument gl_cv_func_getcwd_succeeds_beyond_4k=no is being used and recognized:

:info:configure checking whether getcwd succeeds when 4k < cwd_length < 16k... (cached) no

and yet the problem occurs. This seems to tell us that the ​developer's suggestion to use gl_cv_func_getcwd_succeeds_beyond_4k=no does not work and we should go back to the previous solution we were using.

Please try editing the file /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/gnulib-1.0.tcl (or wherever it is on your system if you sync from a different source) and changing gl_cv_func_getcwd_succeeds_beyond_4k=no to gl_cv_func_getcwd_path_max=yes. Then sudo port clean the affected port and try again.

[ryandesign (Ryan Carsten Schmidt)]

In b434d21d6ae7a89f0a435a98c34b14e69aa2d446/macports-ports (master):

gnulib-1.0.tcl: Use gl_cv_func_getcwd_path_max=yes

New reports indicate gl_cv_func_getcwd_succeeds_beyond_4k=no is not
sufficient.

See: #62994

[ryandesign (Ryan Carsten Schmidt)]

In 69711179cc4c1485a71c1199507152827405725e/macports-ports (master):

gnulib-1.0.tcl: Use "yes, but with shorter paths"

We've seen coreutils report "checking whether getcwd handles long file
names properly... yes, but with shorter paths" when it fails so switch
to gl_cv_func_getcwd_path_max="yes, but with shorter paths".

See: #62994

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

Please try editing

I decided there was no reason to have you do manual testing when we already know the previous solution worked so I put it back, in addition to the new one; no need to use just one. I changed it to gl_cv_func_getcwd_path_max="yes, but with shorter paths" on the basis of comment:35 and attachment:ticket:69770:main.log​. Pavel and Riccardo, if you wait an hour for the rsync server to update, you can just sudo port sync and sudo port clean coreutils and then try again.

[pkoshevoy (Pavel Koshevoy)]

I have applied gl_cv_func_getcwd_path_max="yes, but with shorter paths" change to /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/_resources/port1.0/group/gnulib-1.0.tcl and I was able to install coreutils, thank you