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

[MacPorts]

#62994: various ports fail to install on Leopard due to gnulib issue: /confdir-
14B---: No space left on device
-------------------------------------------+----------------------
  Reporter:  kencu                         |      Owner:  mascguy
      Type:  defect                        |     Status:  assigned
  Priority:  Normal                        |  Milestone:
 Component:  ports                         |    Version:
Resolution:                                |   Keywords:  leopard
      Port:  m4 bison findutils coreutils  |
-------------------------------------------+----------------------

Comment (by ballapete):

 Replying to [comment:32 mascguy]:
 > Replying to [comment:31 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.

-- 
Ticket URL: <https://trac.macports.org/ticket/62994#comment:33>
MacPorts <https://www.macports.org/>
Ports system for macOS