[OpenAFS-devel] RHEL5 builder is failing

Benjamin Kaduk kaduk@MIT.EDU
Sun, 9 Dec 2012 21:12:20 -0500 (EST)


On Sat, 8 Dec 2012, Simon Wilkinson wrote:

>
> On 8 Dec 2012, at 14:47, Jason Edgecombe wrote:
>>
>> /usr/bin/install -c -m 644  /home/jwedgeco/buildslave/rhel5-x86_64-builder/build/include/rx/rxkad.h
>> /usr/bin/install: missing destination file operand after `/home/jwedgeco/buildslave/rhel5-x86_64-builder/build/include/rx/rxkad.h'
>
> I've seen this failure a few times with local builds. It almost always resolves itself with the next run of "make".
>
> As far as I can tell, it happens because of our use of $? in our installation rules. For example, in this case we have:
>
> ${TOP_INCDIR}/rx/rxkad.h: rxkad.h
>        ${INSTALL_DATA} $? $@
>
> The $? automatic variable is defined as expanding to "all of the 
> prerequisites which are newer than the target". It looks like there's 
> some kind of a race in make which can result in $? expanding to an empty 
> string, but I'm not enough of a make expert to explain this, or even to 
> say whether there is some kind of subtle reason why this problem occurs.

If memory serves correctly, I ran into trouble with $? in (compile) rules 
when integrating with FreeBSD's kernel module build framework.  The system 
makefiles added some extra dependencies to all of the object files, and 
these were sometimes considered out-of-date when building, causing 
breakage.  I would have to check the jabber logs from that time to 
remember whether we considered $< as an alternative and rejected it due to 
incompatibilities.

> The obvious fix for OpenAFS, assuming the we don't want to get in to 
> debugging make issues, is to replace all of the occurrences of $? in 
> install rules with the actual name of the file being installed. This is 
> a relatively simple, if tedious, job to do.

1ec64ba50ea8d691cfb126dd40a11370ed37b433 is what I put on master to get my 
libafs problems worked out, but I never had incentive to pick it onto 1.6, 
since my FreeBSD build system integration is not mergable in its current 
form (it changes non-OS-specific build bits).

-Ben