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

 The purpose of the test is described this way:

 {{{
 /* This size is chosen to be larger than PATH_MAX (4k), yet smaller than
    the 16kB pagesize on ia64 linux.  Those conditions make the code below
    trigger a bug in glibc's getcwd implementation before 2.4.90-10.  */
 #define TARGET_LEN (5 * 1024)
 }}}

 Tiger does not have this bug, maybe Leopard as well. So one way to get
 around this `rm` error is to remove the code that builds this directory
 tree. And just write

 {{{
 "#define HAVE_MINIMALLY_WORKING_GETCWD 1"
 "#define HAVE_PARTLY_WORKING_GETCWD 1"
 "#define HAVE_GETCWD_SHORTER 1"
 "#define GNULIB_GETCWD 1"
 "#define GNULIB_TEST_GETCWD 1"
 }}}

 into `confdefs.h`. We just need to be sure…

 The C programme that creates the directory tree is:

 {{{
     1   int
     2   main ()
     3   {
     4     char *cwd;
     5     size_t initial_cwd_len;
     6     int fail = 0;
     7
     8     /* The bug is triggered when PATH_MAX < getpagesize (), so skip
     9        this relatively expensive and invasive test if that's not
 true.  */
    10   #ifdef PATH_MAX
    11     int bug_possible = PATH_MAX < getpagesize ();
    12   #else
    13     int bug_possible = 0;
    14   #endif
    15     if (! bug_possible)
    16       return 0;
    17
    18     cwd = getcwd (NULL, 0);
    19     if (cwd == NULL)
    20       return 2;
    21
    22     initial_cwd_len = strlen (cwd);
    23     free (cwd);
    24
    25     if (1)
    26       {
    27         static char const dir_name[] = "confdir-14B---";
    28         size_t desired_depth = ((TARGET_LEN - 1 - initial_cwd_len)
    29                                 / sizeof dir_name);
    30         size_t d;
    31         for (d = 0; d < desired_depth; d++)
    32           {
    33             if (mkdir (dir_name, S_IRWXU) < 0 || chdir (dir_name) <
 0)
    34               {
    35                 if (! (errno == ERANGE || errno == ENAMETOOLONG
    36                        || errno == ENOENT))
    37                   fail = 3; /* Unable to construct deep hierarchy.
 */
    38                 break;
    39               }
    40           }
    41
    42         /* If libc has the bug in question, this invocation of
 getcwd
    43            results in a failed assertion.  */
    44         cwd = getcwd (NULL, 0);
    45         if (cwd == NULL)
    46           fail = 4; /* getcwd didn't assert, but it failed for a
 long name
    47                        where the answer could have been learned.  */
    48         free (cwd);
    49
    50         /* Call rmdir first, in case the above chdir failed.  */
    51         rmdir (dir_name);
    52         while (0 < d--)
    53           {
    54             if (chdir ("..") < 0)
    55               {
    56                 fail = 5;
    57                 break;
    58               }
    59             rmdir (dir_name);
    60           }
    61       }
    62
    63     return fail;
    64   }
 }}}

 As far as I understand the code the programme changes directory to the one
 it has just created and then creates a new one, until the maximum path
 length is reached. Then it changes directory upwards and removes the
 directory it created before. This latter code, lins #50–60, seems to fail
 because the directory tree is left intact. Does this code need an upgrade?

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