[MacPorts] #63603: bison @3.8.2 does not build on PPC Leopard with GCC 4.2 because confdir-14B---: file name too long

[MacPorts]

#63603: bison @3.8.2  does not build on PPC Leopard with GCC 4.2 because confdir-
14B---: file name too long
------------------------+----------------------
  Reporter:  ballapete  |      Owner:  mascguy
      Type:  defect     |     Status:  assigned
  Priority:  Normal     |  Milestone:
 Component:  ports      |    Version:  2.7.1
Resolution:             |   Keywords:  leopard
      Port:  bison      |
------------------------+----------------------

Comment (by ballapete):

 One clue I found today is that the path name given after the text "Error:
 Failed to configure bison:" in my initial report is exactly 1024
 characters. In
 {{{
 /usr/include/sys/syslimits.h:91:#define PATH_MAX                 1024   /*
 max bytes in pathname */
 }}}
 `PATH_MAX` is `#defined` and then reused in
 {{{
 /usr/include/sys/param.h:198:#define    MAXPATHLEN      PATH_MAX
 }}}
 Finally we get:
 {{{
 /usr/include/stdio.h:216:#define        FILENAME_MAX    1024    /* must be
 <= PATH_MAX <sys/syslimits.h> */
 }}}

 This might explain why the test only sometimes fails – because the longest
 path name is either less than or exactly (`<=`) 1024 bytes. It can't be
 longer, because then it could not be created. The question why `rm`
 sometimes fails to remove the directory hierarchy could be explained by
 assuming that inside MacPorts the text string of 1024 characters is
 limited by a NEWLINE character and becomes this way one character too long
 and illegal.

 In #comment:10 I inserted the C test programme that `configure` runs. It
 actually has a loop that removes the just created directory hierachy, lins
 #50–60. This code seems to fail first, so that `configure` sees the start
 of the directory hierarchy and therefore starts to delete it. And fails,
 too…

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