[Cluster-devel] cluster3 build: libdlm.h and PATH_MAX

[Fabio M. Di Nitto <fdinitto@redhat.com>]

On Wed, 1 Oct 2008, david m. richter wrote:

> hello,
>
> I should've asked on IRC before you folks all left for your
> conference, but these are two things I'd forgotten about until now
> (because I'm setting up a new cluster from scratch).
>
>
> [libdlm.h]
> First, I'm building cluster3 and run into difficulties with finding
> libdlm.h.  In order to coax the build along, I had to modify:
>  - cluster/dlm/tool/Makefile
>  - cluster/dlm/libdlmcontrol/Makefile
>  - cluster/group/dlm_controld
> .. by adding cluster/dlm/libdlm/ as an include directory.
>
> I believe I'd had this trouble in the past with cluster2, as well, and
> just punted and yum installed cman-devel -- but that's an ugly kludge.
>
> My question is: has anyone else noticed anything w/r/t missing
> libdlm.h, and if not have you verified that it's actually getting
> picked up from the cluster source tree and not a pre-existing one in
> /usr/include somewhere?

This is interesting. I assume you are using the last checkout from master. 
can you check the autogenerated file make/defines.mk for paths to 
libdlm.h?

Did you try to reconfigure?

>
> [PATH_MAX]
> I'd had a similar problem before with
> cluster/group/libgfscontrol/libgfscontrol.h, which uses PATH_MAX.
> Builds on my systems blow up because it doesn't #include
> <linux/limits.h>.  I've had the one-liner patch in my tree for months
> and forgot about it until I rebased and excised it, expecting it to be
> vestigial.
>
> Has anyone noticed anything similar?  This one seems pretty clear-cut,
> but something must be screwy somewhere or everyone would've noticed it
> a long time ago.
>

Probably limits.h is pulled in indirectly. I recall seeing this one only 
once because another path to another include was wrong.

Fabio

--
I'm going to make him an offer he can't refuse.