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! 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" >
_______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
