On 8/16/18 12:09 PM, Ian Lepore wrote: > On Thu, 2018-08-16 at 11:25 -0700, Xin LI wrote: >> On Thu, Aug 16, 2018 at 9:26 AM Brad Davis <brd_at_freebsd.org> wrote: >>> >>> >>> On Thu, Aug 16, 2018, at 10:13 AM, Xin LI wrote: >>>> >>>> This was caused by r337852, but I didn't investigated further. >>>> >>>> The problem is that we have a source file called 'moduli.c' in >>>> crypto/openssh/ while the build target was moduli, and bmake seen >>>> 'moduli' in source tree as older than moduli.c, and decided to >>>> rebuild >>>> it from source, while the two files are unrelated. >>> Hi Xin, >>> >>> I don't see how that could be the case as I didn't move the file >>> around, I just moved how it gets installed. >>> >>> I have done many many builds with this change in and haven't seen >>> this problem.. >> Yeah, let me rephrase: this might have been exposed by r337852; I >> don't think your change itself really caused or should have caused >> problem, but my theory based on what we have observed was that it >> might have exposed a bug where either bmake itself, or some .mk files >> might have generated e.g. automatic rule for ${foo}: ${foo}.c rules >> (haven't traced that part down yet). >> > > There is an implicit rule to build file from file.c, it's why you can > type "make foo" in a dir that contains a foo.c and no Makefile. > > The CONFS=moduli makes moduli into a target. The implicit rules search > finds the rule to make moduli from moduli.c and because of the .PATH > it's able to find a moduli.c. > > It might be fixable by simply adding a target with a do-nothing script > for building moduli in usr.sbin/sshd/Makefile. Something like > > moduli: > _at_ : # Do nothing. > > But that's just a wild guess on my part, not sure that'll work. Hmm, in > fact, it'll probably cause a make warning about duplicate targets with > scripts. > > --Ian > >> The most scaring part is that the build system seems to trying >> building crypto/openssh/moduli because moduli.c was newer, and the >> file was deleted as part of the rebuild; should moduli.c compile by >> its own, we would end up with a binary moduli file. >> >> I'll take another look tonight if I had some time. >> >>> >>> >>> >>> Regards, >>> Brad Davis >>> >>>> >>>> On Thu, Aug 16, 2018 at 4:19 AM David Wolfskill <david_at_catwhisker >>>> .org> wrote: >>>>> >>>>> >>>>> Running: >>>>> >>>>> FreeBSD g1-215.catwhisker.org 12.0-ALPHA1 FreeBSD 12.0-ALPHA1 >>>>> #80 r337834M/337834:1200077: Wed Aug 15 04:34:45 PDT 2018 >>>>> root_at_g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/s >>>>> ys/CANARY amd64 >>>>> >>>>> after updating working copy to r337903, I'm seeing: >>>>> >>>>> ... >>>>>> >>>>>>> >>>>>>>> >>>>>>>> stage 4.3: building everything >>>>> ... >>>>> --- ifconfig_make --- >>>>> Building >>>>> /common/S4/obj/usr/src/amd64.amd64/rescue/rescue/usr/src/sbin/i >>>>> fconfig/af_inet6.o >>>>> --- all_subdir_secure --- >>>>> --- moduli --- >>>>> /usr/bin/ld: error: undefined symbol: main >>>>>> r337928 should fix it. -- Regards, Bryan Drewery
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:17 UTC