Re: no decision has been made on APR_PATH_MAX for your platform

Hi,

> It seems the apache/include/apr.h just doesn't see PATH_MAX (defined
> in my /usr/include/linux/limits.h) and so APR_PATH_MAX is not
> defined.

Indeed <linux/limits.h> is not necessarily included by <limits.h>. For
example on a Fedora Core 2 workstation:
* <limits.h> includes <bits/posix1_lim.h> *only if* one of these
     macros (or one that causes them to be defined, see <features.h>
     on GNU systems) is properly defined:
     * _POSIX_SOURCE
     * _POSIX_C_SOURCE
     * _XOPEN_SOURCE
     * _GNU_SOURCE
* <bits/posix1_lim.h> includes <bits/local_lim.h>
* <bits/local_lim.h> includes <linux/limits.h>

The reason is that PATH_MAX is "obsolete" since the maximal path length
may not be known at compile-time. For example a remote disk in an
heterogeneous network may be mounted at run-time using NFS and the
remote system may allow for larger paths. More details here:
http://www.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html

> I tried things like including /usr/include/linux in include path but
> didn't help.
>
> After losing some hair I finally tried "kumar's dangerous hack"
> (thanks!) which fixed the problem, at what cost I know not ;)

This could be an APR bug (it should notify which macros to define when
using apr). Run this command to make sure:
        apr-config --cppflags
On a Fedora core 2 workstation:
        $ apr-config --cppflags
         -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE
        $

This could also a swig bug, if it doesn't take the output of the above
command into account.

As a workaround, define _GNU_SOURCE properly when building swig, it just
a question of adding an option flag to the compiler such as:
        -D_GNU_SOURCE

Dimitri Papadopoulos

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 28 10:19:12 2005