On Wed, Mar 27, 2013 at 5:25 AM, Anders Roxell <[email protected]> wrote: > > On Wed, Mar 20, 2013 at 4:30 PM, Bruce Ashfield <[email protected]> > wrote: >> >> On Wed, Mar 20, 2013 at 10:55 AM, Anders Roxell <[email protected]> >> wrote: >> > >> > >> > >> > On Wed, Mar 20, 2013 at 2:42 PM, Bruce Ashfield >> > <[email protected]> >> > wrote: >> >> >> >> On Wed, Mar 20, 2013 at 9:22 AM, <[email protected]> wrote: >> >> > From: Anders Roxell <[email protected]> >> >> > >> >> > In mainline kernel 3.7-rc1 (hash:abbf1590de22a6d22) >> >> > The path include/linux/version.h was updated to >> >> > include/generated/uapi/linux/version.h >> >> >> >> It's true that uapi now holds the generated version.h, but what build >> >> error were you seeing without this change in place ? >> > >> > >> > We were trying to build linx >> > (http://linx.sourceforge.net/linxdoc/doc/index.html) >> > Please let me know if it is better to rewrite linx or include this >> > patch? >> >> My concern is that as a list of alternatives builds up over time, that >> don't >> necessarily use the same format of the linux version, you'll end up with >> applications that are making the wrong decisions if a fallback is used. >> Having >> a clear public / exported file, and throwing errors if it doesn't exist >> would >> ensure consistent behaviour (granted annoying if you get the error when >> you >> think you shouldn't). >> >> If you look at the code in get_kernelversion() it shouldn't even work if >> version.h is used versus utsrelease.h. I'd be inclined to suggest the >> removal of the existing version.h fallback, versus adding another. >> >> You might not even need to modify the application code to fix this. What >> are the dependencies of your recipe that would allow for utsrelease.h >> to not be generated when the build calls get_kernelversion ? >> > > Sorry for the late response! > I agree with you that its better to use utsrelease.h rather than depending > on version.h. > > We have added a patch for the linx source to solve this. > > Thank you very much for the help and support!
I was wondering about how this went a day or so ago .. and now I know. Glad to hear it worked out! Cheers, Bruce > > With kind regards, > Anders > >> >> Cheers, >> >> Bruce >> >> > >> > Regards, >> > Anders >> > >> >> >> >> utsrelease.h is >> >> still created where it has been for some time, and should be what is >> >> typically used for any version checks. >> >> >> >> Cheers, >> >> >> >> Bruce >> >> >> >> >> >> >> >> > >> >> > Signed-off-by: Anders Roxell <[email protected]> >> >> > --- >> >> > meta/classes/linux-kernel-base.bbclass | 3 +++ >> >> > 1 files changed, 3 insertions(+), 0 deletions(-) >> >> > >> >> > diff --git a/meta/classes/linux-kernel-base.bbclass >> >> > b/meta/classes/linux-kernel-base.bbclass >> >> > index 4f2b0a4..b7d0ffa 100644 >> >> > --- a/meta/classes/linux-kernel-base.bbclass >> >> > +++ b/meta/classes/linux-kernel-base.bbclass >> >> > @@ -8,6 +8,9 @@ def get_kernelversion(p): >> >> > fn = p + '/include/generated/utsrelease.h' >> >> > if not os.path.isfile(fn): >> >> > fn = p + '/include/linux/version.h' >> >> > + if not os.path.isfile(fn): >> >> > + # after 3.7-rc1 >> >> > + fn = p + '/include/generated/uapi/linux/version.h' >> >> > >> >> > import re >> >> > try: >> >> > -- >> >> > 1.7.5.4 >> >> > >> >> > >> >> > _______________________________________________ >> >> > Openembedded-core mailing list >> >> > [email protected] >> >> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core >> >> >> >> >> >> >> >> -- >> >> "Thou shalt not follow the NULL pointer, for chaos and madness await >> >> thee at its end" >> > >> > >> >> >> >> -- >> "Thou shalt not follow the NULL pointer, for chaos and madness await >> thee at its end" > > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
