25.08.2022 11:49, L. van Belle wrote: ...
The shown fix, commit aeaa786aceb0ea781ded2c151fb68f6b34880ad4 is the patch I added. and cifs-utils 7.0 also fails to build without that patch with parallel=1
It's difficult to follow. Commit aeaa786aceb0ea781ded2c151fb68f6b34880ad4 is wrong by its own because it adds dependency on install-sbinPROGRAMS while it should add dependency on install-root_sbinPROGRAMS (which creates the necessary directory). So that commit just adds unnecessary complexity but does not fix the problem in any way. Was it you who added this commit to upstream samba? I didn't notice this difference either, before closing this bug. I thought I verified the single-job build locally but it turned out my -j1 has been overridden by later -j8 on the same command line. Oh well. Technically this dependency is wrong too because the symlink itself does not need the installation of the binary, it needs only the directory. The right fix would be to create directory in its own target and refer in both install- and hook- to that target but I don't know if it is solvable in terms of regular make. GNU make has order-only targets which fits here nicely. But install-root_sbinPROGRAMS target as whole is generated by automake, together with the mkdir call. So the only way to "fix" this is to add similar mkdir into the hook rule, as Sanvilla did in his patch. Now, you wrote above that cifs-utils 7.0 "also fails to build without this patch", but this patch is included in 7.0. This is even more confusing.. :) Anyway. I'm changing install-sbinPROGRAMS to install-root_sbinPROGRAMS there to do what aeaa786aceb0ea781ded2c151fb68f6b34880ad4 has meant to do. This will fix this issue "the way upstream wanted it to be fixed", so to say. Oh well. /mjt
