Skip to contentSkip to conversation

glib-2.0-native: do_compile failed on opensuse 12.2 64bit

PATCH In review Robert Yang 3 participants 9 messages Apr 26, 2013 – May 14, 2013

lore
Share & tools
lore
#0 lore raw

cover glib-2.0-native: do_compile failed on opensuse 12.2 64bit

The following changes since commit addcfcda84ed6b43b00f569a6060e3b78196ef52:

glib-2.0: disable tests for native builds, and respect ptest for LSB (2013-04-23 13:00:43 +0100)

are available in the git repository at:

git://git.pokylinux.org/poky-contrib robert/glib
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/glib

Robert Yang (1):
glib-2.0-native: do_compile failed on opensuse 12.2 64bit

 meta/recipes-core/glib-2.0/glib-2.0_2.34.3.bb |    2 +-
 meta/recipes-core/glib-2.0/glib.inc           |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
Signature · 1 line
1.7.10.4
#1 lore raw

PATCH 1/1 glib-2.0-native: do_compile failed on opensuse 12.2 64bit

The error message:
File "/path/to/glib-2.34.3/gio/gdbus-2.0/codegen/parser.py", line 25, in <module>
import xml.parsers.expat

ImportError: No module named xml.parsers.expat
make[2]: *** [gdbus-daemon-generated.h] Error 1

This is because opensuse 12.2 doesn't install the expat.py (one of python's lib) by default, but our native python provides it, use the native python would fix the problem.

[YOCTO #4424]

---
 meta/recipes-core/glib-2.0/glib-2.0_2.34.3.bb |    2 +-
 meta/recipes-core/glib-2.0/glib.inc           |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
meta/recipes-core/glib-2.0/glib-2.0_2.34.3.bb +1 -1
index 7795524..50f8968 100644
@@ -45,7 +45,7 @@ RDEPENDS_${PN}-ptest_append_libc-glibc = "\
            "
 
 do_configure_prepend() {
-	sed -i -e '1s,#!.*,#!${USRBINPATH}/env python,' ${S}/gio/gdbus-2.0/codegen/gdbus-codegen.in
+	sed -i -e '1s,#!.*,#!${PYTHON},' ${S}/gio/gdbus-2.0/codegen/gdbus-codegen.in
 }
 
 do_install_append() {
meta/recipes-core/glib-2.0/glib.inc +1 -1
index 42c34c3..0b09131 100644
@@ -21,7 +21,7 @@ PACKAGES =+ "${PN}-utils ${PN}-bash-completion ${PN}-codegen"
 LEAD_SONAME = "libglib-2.0.*"
 FILES_${PN}-utils = "${bindir}/* ${datadir}/glib-2.0/gettext"
 
-inherit autotools gettext gtk-doc pkgconfig ptest
+inherit autotools gettext gtk-doc pkgconfig ptest pythonnative
 
 S = "${WORKDIR}/glib-${PV}"
 
Signature · 1 line
1.7.10.4
#2 lore raw

Hi,

Quoted 10 lines · Robert Yang

The error message:
File "/path/to/glib-2.34.3/gio/gdbus-2.0/codegen/parser.py", line 25, in <module>
import xml.parsers.expat

ImportError: No module named xml.parsers.expat
make[2]: *** [gdbus-daemon-generated.h] Error 1

This is because opensuse 12.2 doesn't install the expat.py (one of python's lib) by default, but our native python provides it, use the native python would fix the problem.

I don't like this.

xml.parsers.expat is a standard Python library that's been integrated since 2.0:

http://docs.python.org/2/library/pyexpat.html#module-xml.parsers.expat

If we can't assume that a distribution has shipped a working Python we've got bigger problems.

We could sanity check this in some way, maybe in the recipe's configure step so we can give a nicer message, but I don't think we should depend on pythonnative when we're talking about a standard feature of Python.

Ross

#3 lore raw
Quoted 20 lines · Ross

Hi,

Quoted 10 lines · Robert Yang

The error message:

   File "/path/to/glib-2.34.3/gio/gdbus-2.0/codegen/parser.py", line 25, in <module>
     import xml.parsers.expat

ImportError: No module named xml.parsers.expat
make[2]: *** [gdbus-daemon-generated.h] Error 1

This is because opensuse 12.2 doesn't install the expat.py (one of python's lib) by default, but our native python provides it, use the native python would fix the problem.

I don't like this.

xml.parsers.expat is a standard Python library that's been integrated since 2.0:

http://docs.python.org/2/library/pyexpat.html#module-xml.parsers.expat

Quoted 8 lines

If we can't assume that a distribution has shipped a working Python we've got bigger problems.

We could sanity check this in some way, maybe in the recipe's configure step so we can give a nicer message, but I don't think we should depend on pythonnative when we're talking about a standard feature of Python.

Hi Ross,

Thanks for the review, please see more comments:
The glib-2.0-native had already depend on python-native before this patch, the depends chain is:

glib-2.0-native -> python-argparse-native -> python-native

I inherit the glib-2.0-native is for using the ${PYTHON} variable, it doesn't change its depends, since we had built python-native already, and it works, it seems more reasonable to use it rather than show error message and let the user install other pkgs on the host, I think that this is what our native recipe for.

// Robert

Quoted 3 lines

Ross

#4 lore raw
Quoted 5 lines · Robert Yang

Thanks for the review, please see more comments:
The glib-2.0-native had already depend on python-native before this patch, the depends chain is:

glib-2.0-native -> python-argparse-native -> python-native

That argparse usage was dropped from upstream in 2.30, so we can drop the dependency.

I still think that we shouldn't have to build a whole python because a distribution decided to not install fundamental parts of Python out of the box (python-xml).

Ross

#5 lore raw
Quoted 5 lines · Ross
Quoted 4 lines · Robert Yang

Thanks for the review, please see more comments:
The glib-2.0-native had already depend on python-native before this patch, the depends chain is:

Quoted 8 lines
Quoted 1 line

glib-2.0-native -> python-argparse-native -> python-native

That argparse usage was dropped from upstream in 2.30, so we can drop the dependency.

I still think that we shouldn't have to build a whole python because a distribution decided to not install fundamental parts of Python out of the box (python-xml).

We may need to have a mechanism to specific build dependencies for native depending on host version/distribution.

--
Otavio Salvador O.S. Systems
E-mail: [email protected] http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br

#6 lore raw
Quoted 2 lines · Otavio Salvador

We may need to have a mechanism to specific build dependencies for native depending on host version/distribution.

The situation is that Suse splits the expat parser into a separate package for some reason, so the "fix" is to actually install the whole Python core library by installing python-xml if it isn't already pulled in. We could add a sanity test that the python available is a full python and not missing the expat parser (suse without python-xml) or isn't python-minimal (ubuntu).

Ross

#7 lore raw
Quoted 10 lines · Ross
Quoted 2 lines · Otavio Salvador

We may need to have a mechanism to specific build dependencies for native depending on host version/distribution.

The situation is that Suse splits the expat parser into a separate package for some reason, so the "fix" is to actually install the whole Python core library by installing python-xml if it isn't already pulled in. We could add a sanity test that the python available is a full python and not missing the expat parser (suse without python-xml) or isn't python-minimal (ubuntu).

Yes; this might be a solution.

--
Otavio Salvador O.S. Systems
E-mail: [email protected] http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br

#8 lore raw
In reply to Burton, Ross

OK, got it, I will file a new patch sooner.

// Robert

Quoted 14 lines · Ross
Quoted 2 lines · Otavio Salvador

We may need to have a mechanism to specific build dependencies for native depending on host version/distribution.

The situation is that Suse splits the expat parser into a separate package for some reason, so the "fix" is to actually install the whole Python core library by installing python-xml if it isn't already pulled in. We could add a sanity test that the python available is a full python and not missing the expat parser (suse without python-xml) or isn't python-minimal (ubuntu).

Ross