| Message ID | 1436129545-3540-1-git-send-email-danomimanchego123@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
Danomi, All, On 2015-07-05 16:52 -0400, Danomi Manchego spake thusly: > Drop sed line which no longer changes anything. Worse, it bumps each > ntpd/*.c file's modification time, which sometimes triggers a strange > dependency path causing the makefile to attempt to run the ntpd keyword-gen > app, which fails, because it's been cross-compiled. > > Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com> > > --- > > The deleted sed line is the reason why the keyword-gen source dependency > was being unexpectedly triggered, which prompted my initial patch back > in July 2014, which Thomas P. did not really like as the real reason > for why the initial ntp rebuild works, but the second fails, was not > understood. (See http://patchwork.ozlabs.org/patch/371305/). > > While its true that this patch still does not explore why things sometimes > work differently in subsequent ntp rebuilds, the whole issue can be avoided > by not touching the source unnecessarily. > > Interestingly, someone on one of the ntp mailing lists also encountered > this same issue. (See http://lists.ntp.org/pipermail/questions/2009-October/024669.html) > It doesn't appear that anything came of it. In fact, the fellow > who answered said that if you don't change the source file, then > the derived file delivered with the tarball should be up to date. > > So lets not touch the source unless we have to, especially if we're > not even changing anything. > --- > package/ntp/ntp.mk | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/package/ntp/ntp.mk b/package/ntp/ntp.mk > index 5f05508..93cefa1 100644 > --- a/package/ntp/ntp.mk > +++ b/package/ntp/ntp.mk > @@ -42,7 +42,6 @@ endif > > define NTP_PATCH_FIXUPS > $(SED) "s,^#if.*__GLIBC__.*_BSD_SOURCE.*$$,#if 0," $(@D)/ntpd/refclock_pcf.c As far as I could see, that one line does not do anything either. > - $(SED) '/[[:space:](]rindex[[:space:]]*(/s/[[:space:]]*rindex[[:space:]]*(/ strrchr(/g' $(@D)/ntpd/*.c > endef Indeed, this line does not change anything in the source files... Regards, Yann E. MORIN. > NTP_INSTALL_FILES_$(BR2_PACKAGE_NTP_NTP_KEYGEN) += util/ntp-keygen > -- > 1.9.1 > > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
Yann, >> diff --git a/package/ntp/ntp.mk b/package/ntp/ntp.mk >> index 5f05508..93cefa1 100644 >> --- a/package/ntp/ntp.mk >> +++ b/package/ntp/ntp.mk >> @@ -42,7 +42,6 @@ endif >> >> define NTP_PATCH_FIXUPS >> $(SED) "s,^#if.*__GLIBC__.*_BSD_SOURCE.*$$,#if 0," $(@D)/ntpd/refclock_pcf.c > > As far as I could see, that one line does not do anything either. It *does* change the file - though, I don't know if the change is actually necessary. Verified by doing: $ rm -rf output/build/ntp-4.2.8p3/ $ make -s ntp-extract $ cp -ra output/build/ntp-4.2.8p3/ . $ make -s ntp-patch $ diff ntp-4.2.8p3/ntpd/refclock_pcf.c output/build/ntp-4.2.8p3/ntpd/refclock_pcf.c 170c170 < #if defined(__GLIBC__) && defined(_BSD_SOURCE) --- > #if 0 I imagine that this change is better done via patch than sed, if it's needed at all, but since it is actually doing something, changing it would be a different topic from removing the second line. Danomi -
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes: Hi, >> package/ntp/ntp.mk | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/package/ntp/ntp.mk b/package/ntp/ntp.mk >> index 5f05508..93cefa1 100644 >> --- a/package/ntp/ntp.mk >> +++ b/package/ntp/ntp.mk >> @@ -42,7 +42,6 @@ endif >> >> define NTP_PATCH_FIXUPS >> $(SED) "s,^#if.*__GLIBC__.*_BSD_SOURCE.*$$,#if 0," $(@D)/ntpd/refclock_pcf.c > As far as I could see, that one line does not do anything either. Well, it protects the code in ntpd/refclock_pcf.c (which is for an obscure reference clock kit for the parallel port) which uses the tm_gmtoff member of struct tm - And that one is only available on uClibc if it is built with __UCLIBC_HAS_TM_EXTENSIONS__, so I guess it's a very old build fix for uClibc. Looking at the git history confirms that, as it comes from: commit 7129da009cc72575a84a30c4587bd99f745c49d4 Author: Eric Andersen <andersen@codepoet.org> Date: Sat Jan 18 21:27:22 2003 +0000 Merge a bunch of stuff over from the tuxscreen buildroot, with many updates to make things be more consistant. -Erik With that said, our uClibc configs DO enable __UCLIBC_HAS_TM_EXTENSIONS__, so we can indeed drop it. I'll do so now.
>>>>> "Danomi" == Danomi Manchego <danomimanchego123@gmail.com> writes: > Drop sed line which no longer changes anything. Worse, it bumps each > ntpd/*.c file's modification time, which sometimes triggers a strange > dependency path causing the makefile to attempt to run the ntpd keyword-gen > app, which fails, because it's been cross-compiled. > Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com> Makes sense, and the affected code has indeed been changed upstream so it doesn't do anything sensible any more. From CommitLog: ntpd/cmd_args.c@1.56.1.3 +2 -3 remove unused leftover global specific_interface. rindex() -> strrchr() Committed, thanks.
diff --git a/package/ntp/ntp.mk b/package/ntp/ntp.mk index 5f05508..93cefa1 100644 --- a/package/ntp/ntp.mk +++ b/package/ntp/ntp.mk @@ -42,7 +42,6 @@ endif define NTP_PATCH_FIXUPS $(SED) "s,^#if.*__GLIBC__.*_BSD_SOURCE.*$$,#if 0," $(@D)/ntpd/refclock_pcf.c - $(SED) '/[[:space:](]rindex[[:space:]]*(/s/[[:space:]]*rindex[[:space:]]*(/ strrchr(/g' $(@D)/ntpd/*.c endef NTP_INSTALL_FILES_$(BR2_PACKAGE_NTP_NTP_KEYGEN) += util/ntp-keygen
Drop sed line which no longer changes anything. Worse, it bumps each ntpd/*.c file's modification time, which sometimes triggers a strange dependency path causing the makefile to attempt to run the ntpd keyword-gen app, which fails, because it's been cross-compiled. Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com> --- The deleted sed line is the reason why the keyword-gen source dependency was being unexpectedly triggered, which prompted my initial patch back in July 2014, which Thomas P. did not really like as the real reason for why the initial ntp rebuild works, but the second fails, was not understood. (See http://patchwork.ozlabs.org/patch/371305/). While its true that this patch still does not explore why things sometimes work differently in subsequent ntp rebuilds, the whole issue can be avoided by not touching the source unnecessarily. Interestingly, someone on one of the ntp mailing lists also encountered this same issue. (See http://lists.ntp.org/pipermail/questions/2009-October/024669.html) It doesn't appear that anything came of it. In fact, the fellow who answered said that if you don't change the source file, then the derived file delivered with the tarball should be up to date. So lets not touch the source unless we have to, especially if we're not even changing anything. --- package/ntp/ntp.mk | 1 - 1 file changed, 1 deletion(-)