On 20 July 2016 at 03:48, Patrick Ohly <[email protected]> wrote: > When GCC is at version 4 or 5, parsing the recipe fails with: > > ERROR: ExpansionError during parsing > .../ostro-os/meta-java/recipes-core/openjdk/openjdk-8_72b05.bb > ... > bb.data_smart.ExpansionError: Failure expanding variable CFLAGS, > expression was -O2 -pipe -g -feliminate-unused-debug-types > -fdebug-prefix-map=.../ostro-os/build/tmp-glibc/work/corei7-64-ostro- > linux/openjdk-8/72b05-r0=/usr/src/debug/openjdk-8/72b05-r0 > -fdebug-prefix-map=.../ostro-os/build/tmp-glibc/sysroots/x86_64-linux= > -fdebug-prefix-map=.../ostro-os/build/tmp-glibc/sysroots/intel-corei7-64= > -fstack-protector-strong -D_FORTIFY_SOURCE=2 > ${ <at> version_specific_cflags(d)} -Wno-error=deprecated-declarations which > triggered exception TypeError: can only join an iterable > > That's because FLAGS_GCC<version> may be unset, thus leading to > d.getVar() returning None and ''.join(extraflags) failing. > > The join() is also redundant: extraflags already is a string. It > happened to work because Python treats a string as sequence of > single-character strings, and thus ''.join() re-created the original > string. > > Signed-off-by: Patrick Ohly <[email protected]> > --- > recipes-core/openjdk/openjdk-8-common.inc | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/recipes-core/openjdk/openjdk-8-common.inc > b/recipes-core/openjdk/openjdk-8-common.inc > index 089f907..7ad802a 100644 > --- a/recipes-core/openjdk/openjdk-8-common.inc > +++ b/recipes-core/openjdk/openjdk-8-common.inc > @@ -271,10 +271,8 @@ def version_specific_cflags(d): > # doesn't work anyway. > version = d.getVar('GCCVERSION', expand=True)[0] > > - if int(version) >= 4: > - extraflags = d.getVar('FLAGS_GCC%d' % int(version), True) > - > - return ''.join(extraflags) > + extraflags = d.getVar('FLAGS_GCC%d' % int(version), True) or '' > + return extraflags > > CFLAGS_append = " ${@version_specific_cflags(d)}" > CXXFLAGS_append = " ${@version_specific_cflags(d)}" > -- > 2.1.4
This looks good to me. I have a patch up that does substantially similar, but this one beat me to it. It's also better python. I'm still going to check out icedtea 3's OpenJDK. Their build system does this automatically, but going from the past cross-compiling it may be an issue. > > -- > _______________________________________________ > Openembedded-devel mailing list > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-devel -- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
