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)
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
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 follow-ups: 11 27 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.
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 follow-up: 9 Changed 3 years ago by kencu (Ken)
don't give up! that little patch will fix it, if it keeps happening.
comment:9 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!
comment:11 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.
comment:13 Changed 3 years ago by kencu (Ken)
comment:14 Changed 3 years ago by 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:
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: | new → assigned |
comment:18 Changed 2 years ago by kencu (Ken)
Port: | bison added |
---|
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 device → various 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)
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 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 whenPATH_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.
comment:30 Changed 21 months ago by mascguy (Christopher Nielsen)
Port: | coreutils added |
---|
comment:31 follow-up: 32 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 follow-ups: 33 39 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 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 clean
ed 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 #define
d 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.
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 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)
comment:41 follow-up: 42 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 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?
comment:43 follow-up: 44 Changed 11 months ago by catap (Kirill A. Korinsky)
comment:44 follow-up: 45 Changed 11 months ago by barracuda156
Replying to catap:
In b58da074e58f314a0a760a21c28cfae4ad6aa03e/macports-ports (master):
gettext
also needs this.
comment:45 follow-up: 46 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 Changed 11 months ago by barracuda156
Replying to mascguy:
Replying to barracuda156:
gettext
also needs this.Yep, Kirill included fixes for
gettext
andncurses
too.
Great!
comment:47 follow-up: 50 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 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 follow-up: 52 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 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 follow-up: 61 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 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.)
comment:62 follow-up: 63 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 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
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:66 Changed 6 weeks ago by barracuda156
comment:67 follow-up: 74 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.
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.
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! :)
comment:71 follow-ups: 72 81 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 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 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.)
- 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 follow-up: 76 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 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 follow-up: 78 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 follow-up: 79 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 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 :) ).
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 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/m4about 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, #define
d 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 #define
s 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 follow-up: 89 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 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.
comment:94 follow-up: 95 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
comment:95 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".
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.