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

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

[david m. richter]

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?


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


thanks -- and enjoy Austria (or wherever you folks are having your conference),

  d
  .

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

[david m. richter]

On Wed, Oct 1, 2008 at 3:15 PM, david m. richter <richterd@gmail.com> 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.

Ah, missed a couple more I had to change:
  - cluster/rgmanager/src/clulib/Makefile
  - cluster/rgmanager/src/daemons/Makefile
.. but I generally don't build rgmanager, and the build there didn't
finish completely; there may be other instances.

[snip]

thanks,

  d
  .

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

[Fabio M. Di Nitto]

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.

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