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

[david m. richter]

On Thu, Oct 2, 2008 at 1:58 AM, Fabio M. Di Nitto <fdinitto at redhat.com> wrote:
> 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?

oh good, I found it -- I knew something screwy had to be going on.  my
libdlm.h problem ultimately stemmed from sharing machines and having
more than one person poke at things.  dumb problem, but pleasantly
simple.

>
>>
>> [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.

I don't have anything new here -- really, though, the right thing to
do is have libgfscontrol.h explicitly include limits.h.

thanks for helping clear things up!

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