* [PATCH] file: remove the original magic.h @ 2015-03-26 9:18 Junling Zheng 2015-03-26 9:54 ` Richard Purdie 0 siblings, 1 reply; 13+ messages in thread From: Junling Zheng @ 2015-03-26 9:18 UTC (permalink / raw) To: openembedded-core; +Cc: peifeiyue The magic.h under the src/ directory should be generated by magic.h.in during compiling. However, if we modify the magic.h.in, we can find that sometimes the magic.h would not be generated again, and then we use the original one which is not correct. So remove the original magic.h. Signed-off-by: Junling Zheng <zhengjunling@huawei.com> --- meta/recipes-devtools/file/file_5.22.bb | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/meta/recipes-devtools/file/file_5.22.bb b/meta/recipes-devtools/file/file_5.22.bb index 9c6bb38..f4ee31b 100644 --- a/meta/recipes-devtools/file/file_5.22.bb +++ b/meta/recipes-devtools/file/file_5.22.bb @@ -22,6 +22,12 @@ inherit autotools FILES_${PN} += "${datadir}/misc/*.mgc" +do_configure_prepend() { + if test -f "${B}/src/magic.h"; then + rm -rf ${B}/src/magic.h + fi +} + do_install_append_class-native() { create_cmdline_wrapper ${D}/${bindir}/file \ --magic-file ${datadir}/misc/magic.mgc -- 1.8.3.4 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH] file: remove the original magic.h 2015-03-26 9:18 [PATCH] file: remove the original magic.h Junling Zheng @ 2015-03-26 9:54 ` Richard Purdie 2015-03-26 11:31 ` Junling Zheng 0 siblings, 1 reply; 13+ messages in thread From: Richard Purdie @ 2015-03-26 9:54 UTC (permalink / raw) To: Junling Zheng; +Cc: peifeiyue, openembedded-core On Thu, 2015-03-26 at 09:18 +0000, Junling Zheng wrote: > The magic.h under the src/ directory should be generated by magic.h.in > during compiling. However, if we modify the magic.h.in, we can find that > sometimes the magic.h would not be generated again, and then we use the > original one which is not correct. So remove the original magic.h. > > Signed-off-by: Junling Zheng <zhengjunling@huawei.com> > --- > meta/recipes-devtools/file/file_5.22.bb | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/meta/recipes-devtools/file/file_5.22.bb b/meta/recipes-devtools/file/file_5.22.bb > index 9c6bb38..f4ee31b 100644 > --- a/meta/recipes-devtools/file/file_5.22.bb > +++ b/meta/recipes-devtools/file/file_5.22.bb > @@ -22,6 +22,12 @@ inherit autotools > > FILES_${PN} += "${datadir}/misc/*.mgc" > > +do_configure_prepend() { > + if test -f "${B}/src/magic.h"; then > + rm -rf ${B}/src/magic.h > + fi > +} > + If the task checksums change, ${B} should get entirely wiped out with recent releases of the build system (e.g. dizzy/fido/master). Which version was this tested and found to be needed with? Cheers, Richard ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] file: remove the original magic.h 2015-03-26 9:54 ` Richard Purdie @ 2015-03-26 11:31 ` Junling Zheng 2015-03-26 11:58 ` Jack Mitchell 0 siblings, 1 reply; 13+ messages in thread From: Junling Zheng @ 2015-03-26 11:31 UTC (permalink / raw) To: Richard Purdie; +Cc: peifeiyue, openembedded-core On 2015/3/26 17:54, Richard Purdie wrote: > On Thu, 2015-03-26 at 09:18 +0000, Junling Zheng wrote: >> The magic.h under the src/ directory should be generated by magic.h.in >> during compiling. However, if we modify the magic.h.in, we can find that >> sometimes the magic.h would not be generated again, and then we use the >> original one which is not correct. So remove the original magic.h. >> >> Signed-off-by: Junling Zheng <zhengjunling@huawei.com> >> --- >> meta/recipes-devtools/file/file_5.22.bb | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/meta/recipes-devtools/file/file_5.22.bb b/meta/recipes-devtools/file/file_5.22.bb >> index 9c6bb38..f4ee31b 100644 >> --- a/meta/recipes-devtools/file/file_5.22.bb >> +++ b/meta/recipes-devtools/file/file_5.22.bb >> @@ -22,6 +22,12 @@ inherit autotools >> >> FILES_${PN} += "${datadir}/misc/*.mgc" >> >> +do_configure_prepend() { >> + if test -f "${B}/src/magic.h"; then >> + rm -rf ${B}/src/magic.h >> + fi >> +} >> + > > If the task checksums change, ${B} should get entirely wiped out with > recent releases of the build system (e.g. dizzy/fido/master). Which > version was this tested and found to be needed with? > > Cheers, > > Richard > This is tested in the Yocto 1.5 poky-dora-10.0.0, which uses the dora branch of oe-core. But I don't know which version it is actually in oe-core. And I think all branches in oe-core need this fix. Should ${B} be replaced by ${S}? Although sometimes they're not the same:) And I am puzzled why ${B} should be wiped out, and does it be replaced by any other variable except ${S}? Cheers, Junling ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] file: remove the original magic.h 2015-03-26 11:31 ` Junling Zheng @ 2015-03-26 11:58 ` Jack Mitchell 2015-03-26 12:58 ` Junling Zheng 0 siblings, 1 reply; 13+ messages in thread From: Jack Mitchell @ 2015-03-26 11:58 UTC (permalink / raw) To: openembedded-core On 26/03/15 11:31, Junling Zheng wrote: > On 2015/3/26 17:54, Richard Purdie wrote: >> On Thu, 2015-03-26 at 09:18 +0000, Junling Zheng wrote: >>> The magic.h under the src/ directory should be generated by magic.h.in >>> during compiling. However, if we modify the magic.h.in, we can find that >>> sometimes the magic.h would not be generated again, and then we use the >>> original one which is not correct. So remove the original magic.h. >>> >>> Signed-off-by: Junling Zheng <zhengjunling@huawei.com> >>> --- >>> meta/recipes-devtools/file/file_5.22.bb | 6 ++++++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git a/meta/recipes-devtools/file/file_5.22.bb b/meta/recipes-devtools/file/file_5.22.bb >>> index 9c6bb38..f4ee31b 100644 >>> --- a/meta/recipes-devtools/file/file_5.22.bb >>> +++ b/meta/recipes-devtools/file/file_5.22.bb >>> @@ -22,6 +22,12 @@ inherit autotools >>> >>> FILES_${PN} += "${datadir}/misc/*.mgc" >>> >>> +do_configure_prepend() { >>> + if test -f "${B}/src/magic.h"; then >>> + rm -rf ${B}/src/magic.h >>> + fi >>> +} >>> + >> If the task checksums change, ${B} should get entirely wiped out with >> recent releases of the build system (e.g. dizzy/fido/master). Which >> version was this tested and found to be needed with? >> >> Cheers, >> >> Richard >> > This is tested in the Yocto 1.5 poky-dora-10.0.0, which uses the dora branch of oe-core. > But I don't know which version it is actually in oe-core. And I think all branches in > oe-core need this fix. > > Should ${B} be replaced by ${S}? Although sometimes they're not the same:) > > And I am puzzled why ${B} should be wiped out, and does it be replaced by any other variable > except ${S}? > > Cheers, > > Junling > Could this be related to my outstanding bug? There is definitely something odd going on around the file magic binary. https://bugzilla.yoctoproject.org/show_bug.cgi?id=7232 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] file: remove the original magic.h 2015-03-26 11:58 ` Jack Mitchell @ 2015-03-26 12:58 ` Junling Zheng 2015-03-26 13:08 ` Burton, Ross 0 siblings, 1 reply; 13+ messages in thread From: Junling Zheng @ 2015-03-26 12:58 UTC (permalink / raw) To: Jack Mitchell; +Cc: peifeiyue, openembedded-core On 2015/3/26 19:58, Jack Mitchell wrote: > > > On 26/03/15 11:31, Junling Zheng wrote: >> On 2015/3/26 17:54, Richard Purdie wrote: >>> On Thu, 2015-03-26 at 09:18 +0000, Junling Zheng wrote: >>>> The magic.h under the src/ directory should be generated by magic.h.in >>>> during compiling. However, if we modify the magic.h.in, we can find that >>>> sometimes the magic.h would not be generated again, and then we use the >>>> original one which is not correct. So remove the original magic.h. >>>> >>>> Signed-off-by: Junling Zheng <zhengjunling@huawei.com> >>>> --- >>>> meta/recipes-devtools/file/file_5.22.bb | 6 ++++++ >>>> 1 file changed, 6 insertions(+) >>>> >>>> diff --git a/meta/recipes-devtools/file/file_5.22.bb b/meta/recipes-devtools/file/file_5.22.bb >>>> index 9c6bb38..f4ee31b 100644 >>>> --- a/meta/recipes-devtools/file/file_5.22.bb >>>> +++ b/meta/recipes-devtools/file/file_5.22.bb >>>> @@ -22,6 +22,12 @@ inherit autotools >>>> FILES_${PN} += "${datadir}/misc/*.mgc" >>>> +do_configure_prepend() { >>>> + if test -f "${B}/src/magic.h"; then >>>> + rm -rf ${B}/src/magic.h >>>> + fi >>>> +} >>>> + >>> If the task checksums change, ${B} should get entirely wiped out with >>> recent releases of the build system (e.g. dizzy/fido/master). Which >>> version was this tested and found to be needed with? >>> >>> Cheers, >>> >>> Richard >>> >> This is tested in the Yocto 1.5 poky-dora-10.0.0, which uses the dora branch of oe-core. >> But I don't know which version it is actually in oe-core. And I think all branches in >> oe-core need this fix. >> >> Should ${B} be replaced by ${S}? Although sometimes they're not the same:) >> >> And I am puzzled why ${B} should be wiped out, and does it be replaced by any other variable >> except ${S}? >> >> Cheers, >> >> Junling >> > > Could this be related to my outstanding bug? There is definitely something odd going on around the file magic binary. > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=7232 > Um, I don't think it is related to your bug... This problem is that sometimes the magic.h wouldn't be generated again by magic.h.in if there is already an original magic.h, and we may get an unexpected header file. Your bug looks like something is lack in your sysroots... Cheers, Junling ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] file: remove the original magic.h 2015-03-26 12:58 ` Junling Zheng @ 2015-03-26 13:08 ` Burton, Ross 2015-03-27 3:31 ` Junling Zheng 0 siblings, 1 reply; 13+ messages in thread From: Burton, Ross @ 2015-03-26 13:08 UTC (permalink / raw) To: Junling Zheng; +Cc: OE-core, peifeiyue [-- Attachment #1: Type: text/plain, Size: 791 bytes --] On 26 March 2015 at 12:58, Junling Zheng <zhengjunling@huawei.com> wrote: > This problem is that sometimes the magic.h wouldn't be generated again by > magic.h.in if there > is already an original magic.h, and we may get an unexpected header file. > libmagic_la_SOURCES = magic.c apprentice.c softmagic.c ascmagic.c \ encoding.c compress.c is_tar.c readelf.c print.c fsmagic.c \ funcs.c file.h readelf.h tar.h apptype.c \ file_opts.h elfclass.h mygetopt.h cdf.c cdf_time.c readcdf.c cdf.h The problem is that the makefile doesn't actually say that the magic binaries depend on magic.h, so make is perfectly reasonably to build the binaries and then re-generate the makefile. The correct fix here is to add magic.h to libmagic_la_SOURCES. Ross [-- Attachment #2: Type: text/html, Size: 1562 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] file: remove the original magic.h 2015-03-26 13:08 ` Burton, Ross @ 2015-03-27 3:31 ` Junling Zheng 2015-03-27 9:56 ` Burton, Ross 0 siblings, 1 reply; 13+ messages in thread From: Junling Zheng @ 2015-03-27 3:31 UTC (permalink / raw) To: Burton, Ross; +Cc: OE-core, peifeiyue On 2015/3/26 21:08, Burton, Ross wrote: > > On 26 March 2015 at 12:58, Junling Zheng <zhengjunling@huawei.com <mailto:zhengjunling@huawei.com>> wrote: > > This problem is that sometimes the magic.h wouldn't be generated again by magic.h.in <http://magic.h.in> if there > is already an original magic.h, and we may get an unexpected header file. > > > libmagic_la_SOURCES = magic.c apprentice.c softmagic.c ascmagic.c \ > encoding.c compress.c is_tar.c readelf.c print.c fsmagic.c \ > funcs.c file.h readelf.h tar.h apptype.c \ > file_opts.h elfclass.h mygetopt.h cdf.c cdf_time.c readcdf.c cdf.h > > The problem is that the makefile doesn't actually say that the magic binaries depend on magic.h, so make is perfectly reasonably to build the binaries and then re-generate the makefile. > > The correct fix here is to add magic.h to libmagic_la_SOURCES. > > Ross > Hi, Ross I don't think the dependency is the true reason, and I have tested it. I add the magic.h to libmagic_la_SOURCES, and then make several times. However, it's disappointing that sometimes the magic.h does still not generated again by the different magic.h.in. I think the dependency of magic.h for magic binaries has been already declared in Makefile: BUILT_SOURCES = magic.h all: $(BUILT_SOURCES) $(MAKE) $(AM_MAKEFLAGS) all-am The following is the comparison of the incorrect and the correct log of compiling: z00238152@Patch-Test:~>0$ diff -ru log.do_compile.incorrect log.do_compile.correct --- log.do_compile.incorrect 2015-03-27 11:05:23.000000000 +0800 +++ log.do_compile.correct 2015-03-27 11:09:27.000000000 +0800 @@ -5,6 +5,7 @@ make[1]: Entering directory `/home/z00238152/halogen/build-fluorine-arma9el-qemu-HULK/tmp-eglibc/work/armv7a-euler-linux-gnueabi/file/5.14-r0/file-5.14' Making all in src make[2]: Entering directory `/home/z00238152/halogen/build-fluorine-arma9el-qemu-HULK/tmp-eglibc/work/armv7a-euler-linux-gnueabi/file/5.14-r0/file-5.14/src' +sed -e "s/X.YY/$(echo 5.14 | tr -d .)/" < ../src/magic.h.in > magic.h make all-am make[3]: Entering directory `/home/z00238152/halogen/build-fluorine-arma9el-qemu-HULK/tmp-eglibc/work/armv7a-euler-linux-gnueabi/file/5.14-r0/file-5.14/src' And the Makefile in src directory is the same: z00238152@Patch-Test:~>0$ diff -ru Makefile.incorrect Makefile.correct z00238152@Patch-Test:~>0$ And I set the PARALLEL_MAKE ?= "-j 1", the problem also doesn't be fixed. So I think the true reason is that if the magic.h exists already, sometimes Makefile will not generate it again. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] file: remove the original magic.h 2015-03-27 3:31 ` Junling Zheng @ 2015-03-27 9:56 ` Burton, Ross 2015-03-28 2:36 ` Junling Zheng 0 siblings, 1 reply; 13+ messages in thread From: Burton, Ross @ 2015-03-27 9:56 UTC (permalink / raw) To: Junling Zheng; +Cc: OE-core, peifeiyue [-- Attachment #1: Type: text/plain, Size: 301 bytes --] On 27 March 2015 at 03:31, Junling Zheng <zhengjunling@huawei.com> wrote: > So I think the true reason is that if the magic.h exists already, > sometimes Makefile will not generate it again. > In that case it's likely entirely down to timestamps. How are you modifying magic.h.in? Ross [-- Attachment #2: Type: text/html, Size: 726 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] file: remove the original magic.h 2015-03-27 9:56 ` Burton, Ross @ 2015-03-28 2:36 ` Junling Zheng 2015-03-28 8:53 ` Richard Purdie 0 siblings, 1 reply; 13+ messages in thread From: Junling Zheng @ 2015-03-28 2:36 UTC (permalink / raw) To: Burton, Ross; +Cc: OE-core, peifeiyue On 2015/3/27 17:56, Burton, Ross wrote: > > On 27 March 2015 at 03:31, Junling Zheng <zhengjunling@huawei.com <mailto:zhengjunling@huawei.com>> wrote: > > So I think the true reason is that if the magic.h exists already, sometimes Makefile will not generate it again. > > > In that case it's likely entirely down to timestamps. How are you modifying magic.h.in <http://magic.h.in>? > > Ross > Hi, Ross I backport some commits from upstream to fix CVE-2014-9620, and some of them involve the modifying of magic.h.in: 90018fe22ff8b74a22fcd142225b0a00f3f12677 6ce24f35cd4a43c4bdd249e8e0c4952c1f8eac67 0056ec32255de1de973574b0300161a1568767d6 09e41625c999a2e5b51e1092f0ef2432a99b5c33 ce90e05774dd77d86cfc8dfa6da57b32816841c4 And the final difference between magic.h and magic.h.in is: z00238152@Patch-Test:file-5.14>0$ diff -u src/magic.h src/magic.h magic.h magic.h.in z00238152@Patch-Test:file-5.14>0$ diff -u src/magic.h src/magic.h.in --- src/magic.h 2015-03-28 02:01:46.000000000 +0000 +++ src/magic.h.in 2015-03-28 02:01:47.000000000 +0000 @@ -74,7 +74,7 @@ #define MAGIC_NO_CHECK_FORTRAN 0x000000 /* Don't check ascii/fortran */ #define MAGIC_NO_CHECK_TROFF 0x000000 /* Don't check ascii/troff */ -#define MAGIC_VERSION 514 /* This implementation */ +#define MAGIC_VERSION X.YY /* This implementation */ #ifdef __cplusplus @@ -100,7 +100,12 @@ int magic_list(magic_t, const char *); int magic_errno(magic_t); -#define MAGIC_PARAM_MAX_RECURSION 0 +#define MAGIC_PARAM_INDIR_MAX 0 +#define MAGIC_PARAM_NAME_MAX 1 +#define MAGIC_PARAM_ELF_PHNUM_MAX 2 +#define MAGIC_PARAM_ELF_SHNUM_MAX 3 +#define MAGIC_PARAM_ELF_NOTES_MAX 4 + int magic_setparam(magic_t, int, const void *); int magic_getparam(magic_t, int, void *); So, if Makefile doesn't generate a new magic.h, there will be some "symbol undeclared" errors during compiling. By the way, the upstream code has only magic.h.in, and no magic.h, which only exists in release version tarballs. And I think the original magic.h is redundant. Cheers, Junling ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] file: remove the original magic.h 2015-03-28 2:36 ` Junling Zheng @ 2015-03-28 8:53 ` Richard Purdie 2015-03-28 9:37 ` Junling Zheng 0 siblings, 1 reply; 13+ messages in thread From: Richard Purdie @ 2015-03-28 8:53 UTC (permalink / raw) To: Junling Zheng; +Cc: peifeiyue, OE-core On Sat, 2015-03-28 at 10:36 +0800, Junling Zheng wrote: > I backport some commits from upstream to fix CVE-2014-9620, and some of them involve the modifying of magic.h.in: > > 90018fe22ff8b74a22fcd142225b0a00f3f12677 > 6ce24f35cd4a43c4bdd249e8e0c4952c1f8eac67 > 0056ec32255de1de973574b0300161a1568767d6 > 09e41625c999a2e5b51e1092f0ef2432a99b5c33 > ce90e05774dd77d86cfc8dfa6da57b32816841c4 > > And the final difference between magic.h and magic.h.in is: > > z00238152@Patch-Test:file-5.14>0$ diff -u src/magic.h src/magic.h > magic.h magic.h.in > z00238152@Patch-Test:file-5.14>0$ diff -u src/magic.h src/magic.h.in > --- src/magic.h 2015-03-28 02:01:46.000000000 +0000 > +++ src/magic.h.in 2015-03-28 02:01:47.000000000 +0000 > @@ -74,7 +74,7 @@ > #define MAGIC_NO_CHECK_FORTRAN 0x000000 /* Don't check ascii/fortran */ > #define MAGIC_NO_CHECK_TROFF 0x000000 /* Don't check ascii/troff */ > > -#define MAGIC_VERSION 514 /* This implementation */ > +#define MAGIC_VERSION X.YY /* This implementation */ > > > #ifdef __cplusplus > @@ -100,7 +100,12 @@ > int magic_list(magic_t, const char *); > int magic_errno(magic_t); > > -#define MAGIC_PARAM_MAX_RECURSION 0 > +#define MAGIC_PARAM_INDIR_MAX 0 > +#define MAGIC_PARAM_NAME_MAX 1 > +#define MAGIC_PARAM_ELF_PHNUM_MAX 2 > +#define MAGIC_PARAM_ELF_SHNUM_MAX 3 > +#define MAGIC_PARAM_ELF_NOTES_MAX 4 > + > int magic_setparam(magic_t, int, const void *); > int magic_getparam(magic_t, int, void *); > > > So, if Makefile doesn't generate a new magic.h, there will be some "symbol undeclared" errors during compiling. > > By the way, the upstream code has only magic.h.in, and no magic.h, which only exists in release version tarballs. > > And I think the original magic.h is redundant. We ran into this problem in our branches. You need to ensure that your CVE patches just touch magic.h.in and *not* magic.h. If you do that, the timestamp of magic.h.in will be more recent that magic.h and your build will function correctly. The problem is that patch can patch those two files "at the same time" on fast machines. You should never patch generated filed in patches in OE in general. Cheers, Richard ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] file: remove the original magic.h 2015-03-28 8:53 ` Richard Purdie @ 2015-03-28 9:37 ` Junling Zheng 2015-03-28 11:05 ` Richard Purdie 0 siblings, 1 reply; 13+ messages in thread From: Junling Zheng @ 2015-03-28 9:37 UTC (permalink / raw) To: Richard Purdie; +Cc: peifeiyue, OE-core On 2015/3/28 16:53, Richard Purdie wrote: > On Sat, 2015-03-28 at 10:36 +0800, Junling Zheng wrote: >> I backport some commits from upstream to fix CVE-2014-9620, and some of them involve the modifying of magic.h.in: >> >> 90018fe22ff8b74a22fcd142225b0a00f3f12677 >> 6ce24f35cd4a43c4bdd249e8e0c4952c1f8eac67 >> 0056ec32255de1de973574b0300161a1568767d6 >> 09e41625c999a2e5b51e1092f0ef2432a99b5c33 >> ce90e05774dd77d86cfc8dfa6da57b32816841c4 >> >> And the final difference between magic.h and magic.h.in is: >> >> z00238152@Patch-Test:file-5.14>0$ diff -u src/magic.h src/magic.h >> magic.h magic.h.in >> z00238152@Patch-Test:file-5.14>0$ diff -u src/magic.h src/magic.h.in >> --- src/magic.h 2015-03-28 02:01:46.000000000 +0000 >> +++ src/magic.h.in 2015-03-28 02:01:47.000000000 +0000 >> @@ -74,7 +74,7 @@ >> #define MAGIC_NO_CHECK_FORTRAN 0x000000 /* Don't check ascii/fortran */ >> #define MAGIC_NO_CHECK_TROFF 0x000000 /* Don't check ascii/troff */ >> >> -#define MAGIC_VERSION 514 /* This implementation */ >> +#define MAGIC_VERSION X.YY /* This implementation */ >> >> >> #ifdef __cplusplus >> @@ -100,7 +100,12 @@ >> int magic_list(magic_t, const char *); >> int magic_errno(magic_t); >> >> -#define MAGIC_PARAM_MAX_RECURSION 0 >> +#define MAGIC_PARAM_INDIR_MAX 0 >> +#define MAGIC_PARAM_NAME_MAX 1 >> +#define MAGIC_PARAM_ELF_PHNUM_MAX 2 >> +#define MAGIC_PARAM_ELF_SHNUM_MAX 3 >> +#define MAGIC_PARAM_ELF_NOTES_MAX 4 >> + >> int magic_setparam(magic_t, int, const void *); >> int magic_getparam(magic_t, int, void *); >> >> >> So, if Makefile doesn't generate a new magic.h, there will be some "symbol undeclared" errors during compiling. >> >> By the way, the upstream code has only magic.h.in, and no magic.h, which only exists in release version tarballs. >> >> And I think the original magic.h is redundant. > > We ran into this problem in our branches. You need to ensure that your > CVE patches just touch magic.h.in and *not* magic.h. If you do that, the > timestamp of magic.h.in will be more recent that magic.h and your build > will function correctly. > > The problem is that patch can patch those two files "at the same time" > on fast machines. You should never patch generated filed in patches in > OE in general. > > Cheers, > > Richard > Hi, Richard You're right. My CVE patches indeed touch the original magic.h, and that's also why this problem reproduces probabilistic. I remove the modifying of magic.h in my patches, and this problem seems to be fixed. However, I still think the origin magic.h is confusing and redundant...:) Thanks, Junling ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] file: remove the original magic.h 2015-03-28 9:37 ` Junling Zheng @ 2015-03-28 11:05 ` Richard Purdie 2015-03-30 1:49 ` Junling Zheng 0 siblings, 1 reply; 13+ messages in thread From: Richard Purdie @ 2015-03-28 11:05 UTC (permalink / raw) To: Junling Zheng; +Cc: peifeiyue, OE-core On Sat, 2015-03-28 at 17:37 +0800, Junling Zheng wrote: > On 2015/3/28 16:53, Richard Purdie wrote: > > On Sat, 2015-03-28 at 10:36 +0800, Junling Zheng wrote: > > We ran into this problem in our branches. You need to ensure that your > > CVE patches just touch magic.h.in and *not* magic.h. If you do that, the > > timestamp of magic.h.in will be more recent that magic.h and your build > > will function correctly. > > > > The problem is that patch can patch those two files "at the same time" > > on fast machines. You should never patch generated filed in patches in > > OE in general. > > > > Cheers, > > > > Richard > > > Hi, Richard > > You're right. My CVE patches indeed touch the original magic.h, and that's also why this problem reproduces probabilistic. > > I remove the modifying of magic.h in my patches, and this problem seems to be fixed. > > However, I still think the origin magic.h is confusing and redundant...:) There is actually more to this. magic.h is listed as a BUILT_SOURCES file which means it is not regenerated by the usual dependency magic and timestamps, only if it doesn't exist or you run make all/check/install. http://www.gnu.org/software/automake/manual/html_node/Sources.html So you do need it in your patch however you need to ensure your patch generates a magic.h which matches magic.h.in. Cheers, Richard ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] file: remove the original magic.h 2015-03-28 11:05 ` Richard Purdie @ 2015-03-30 1:49 ` Junling Zheng 0 siblings, 0 replies; 13+ messages in thread From: Junling Zheng @ 2015-03-30 1:49 UTC (permalink / raw) To: Richard Purdie; +Cc: peifeiyue, OE-core On 2015/3/28 19:05, Richard Purdie wrote: > On Sat, 2015-03-28 at 17:37 +0800, Junling Zheng wrote: >> On 2015/3/28 16:53, Richard Purdie wrote: >>> On Sat, 2015-03-28 at 10:36 +0800, Junling Zheng wrote: >>> We ran into this problem in our branches. You need to ensure that your >>> CVE patches just touch magic.h.in and *not* magic.h. If you do that, the >>> timestamp of magic.h.in will be more recent that magic.h and your build >>> will function correctly. >>> >>> The problem is that patch can patch those two files "at the same time" >>> on fast machines. You should never patch generated filed in patches in >>> OE in general. >>> >>> Cheers, >>> >>> Richard >>> >> Hi, Richard >> >> You're right. My CVE patches indeed touch the original magic.h, and that's also why this problem reproduces probabilistic. >> >> I remove the modifying of magic.h in my patches, and this problem seems to be fixed. >> >> However, I still think the origin magic.h is confusing and redundant...:) > > There is actually more to this. magic.h is listed as a BUILT_SOURCES > file which means it is not regenerated by the usual dependency magic and > timestamps, only if it doesn't exist or you run make all/check/install. > > http://www.gnu.org/software/automake/manual/html_node/Sources.html > > So you do need it in your patch however you need to ensure your patch > generates a magic.h which matches magic.h.in. > > Cheers, > > Richard > I get it! Thanks a lot for your detailed explanation:) Cheers, Junling ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2015-03-30 1:50 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-03-26 9:18 [PATCH] file: remove the original magic.h Junling Zheng 2015-03-26 9:54 ` Richard Purdie 2015-03-26 11:31 ` Junling Zheng 2015-03-26 11:58 ` Jack Mitchell 2015-03-26 12:58 ` Junling Zheng 2015-03-26 13:08 ` Burton, Ross 2015-03-27 3:31 ` Junling Zheng 2015-03-27 9:56 ` Burton, Ross 2015-03-28 2:36 ` Junling Zheng 2015-03-28 8:53 ` Richard Purdie 2015-03-28 9:37 ` Junling Zheng 2015-03-28 11:05 ` Richard Purdie 2015-03-30 1:49 ` Junling Zheng
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.