From mboxrd@z Thu Jan 1 00:00:00 1970 From: david m. richter Date: Thu, 2 Oct 2008 09:01:50 -0400 Subject: [Cluster-devel] cluster3 build: libdlm.h and PATH_MAX In-Reply-To: References: <1d07ca700810011215p10d441bge4495cd10a74d754@mail.gmail.com> Message-ID: <1d07ca700810020601g678c8464h1c13893308c9daf8@mail.gmail.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, Oct 2, 2008 at 1:58 AM, Fabio M. Di Nitto 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 >> . 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. >