Bug#1120617: openmpi: FTBFS on hurd-amd64 since PATH_MAX is not defined

[Drew Parsons]

Source: openmpi
Version: 5.0.9-1
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: debian-hurd at lists.debian.org
User: debian-hurd at lists.debian.org
Usertags: hurd-amd64

openmpi is failing to build on hurd-amd64:

  CC       src/str/mpl_str.lo
../../../../../3rd-party/romio341/mpl/src/str/mpl_str.c: In function 'MPL_create_pathname':
../../../../../3rd-party/romio341/mpl/src/str/mpl_str.c:417:37: error: 'PATH_MAX' undeclared (first use in this function)
  417 |         MPL_snprintf(dest_filename, PATH_MAX, "%s/%s.%u.%u%c", dirname, prefix,
      |                                     ^~~~~~~~
../../../../../3rd-party/romio341/mpl/src/str/mpl_str.c:417:37: note: each undeclared identifier is reported only once for each function it appears in
make[5]: *** [Makefile:1161: src/str/mpl_str.lo] Error 1


The problem is kind of common on hurd.  A lot of packages like to use
MAXPATHLEN (or PATH_MAX in this case), but it's not actually a
mandatory element in the POSIX standard. So hurd chooses not to
provide it. On Linux (amd64) it's defined in /usr/include/x86_64-linux-gnu/sys/param.h

There is some discussion of the situation at
https://www.gnu.org/software/hurd/community/gsoc/project_ideas/maxpath.html

A robust way to manage it is to refactor to use dynamic memory
allocation without needing to provide PATH_MAX.

But a simpler workaround is to just give it a reasonable value (say
1000) if it's not already defined.

I'm not sure if we want to bug openmpi (or romio341) upstream about it.
But on the other hand openpmix accepted a patch for it,
https://github.com/openpmix/openpmix/issues/3671
https://github.com/openpmix/openpmix/pull/3672