On Tue, May 13, 2014 at 4:38 AM, Gerlando Falauto <gerlando.fala...@keymile.com> wrote: > Hi Jesper, > > [...] > >> I *thought* I was running on python2.7 but as it turns out I was not. >> >> When resolving "python" I get python2.7 but when I check the explicit >> version laying at /usr/bin/python its actually a 2.4 version so no wonder it >> was failing. >> >> Checking the PEP for when "except XX as yy" was introduced points to that >> it was introduced in python 2.6 so entirely my mistake. >> Reran it now with the a 2.7 version and it works as intended. >> >> However, I still think you should run it through env as proposed in the >> patch and not use the explicit path to python. > > > I still have some issues, even with this change. > As a matter of fact, my default python installation would be a python2.6: > > $ python > > python > Python 2.6.6 (r266:84292, Jan 22 2014, 05:06:49) > > I'm however cross-compiling, so I specify a sysroot and I explicitly set the > python version in my configure script: > > $ . /opt/eldk/eldk_init ppc_6xx # set the env for cross-compiling > > $ python2.7 > Python 2.7.3 (default, Aug 2 2013, 20:37:10) > [GCC 4.7.2] on linux2 > > $ which python2.7 > /opt/eldk/powerpc/sysroots/i686-eldk-linux/usr/bin/python2.7 > > $ ac_cv_header_linux_perf_event_h=no PYTHON=python2.7 ./configure > --target=powerpc-linux --host=powerpc-linux --build=i686-linux > --with-libtool-sysroot=/opt/eldk/powerpc/sysroots/powerpc-linux > --prefix=/usr > > $ MAKEFLAGS= && DESTDIR=/opt/eldk/powerpc/sysroots/powerpc-linux make all > install install-strip pkgconfigdir=/tmp pkgconfig_DATA= > > This doesn't however help, as the script will call "python" from the current > environment (thereby ignoring the PYTHON= value used by the configure script > when checking for python version). > > So perhaps a solution would be to change the configure script (or whatever > it comes from by means of autoconfig/automake) so to create a "python" > symlink in the working directory (to the version selected/detected) and then > add it to the path (*). > > I guess a quick-and-dirty alternative could be to change the makefile so to > use the "PYTHON" environment variable to explictly set what interpreter to > use -- but that would defeat the whole purpose of the shebang so I believe > it's a very bad idea: > > --- a/doc/examples/gen-tp/Makefile > +++ b/doc/examples/gen-tp/Makefile > @@ -46,7 +46,7 @@ sample.o: sample.c sample_tracepoint.h > CFLAGS="$(CFLAGS) $(AM_CFLAGS)" \ > LDFLAGS="$(LDFLAGS) $(AM_LDFLAGS)" \ > CC="$(CC)" \ > - $(LTTNG_GEN_TP_PATH)lttng-gen-tp -o $@ $< > + $(PYTHON) $(LTTNG_GEN_TP_PATH)lttng-gen-tp -o $@ $< > > # The following rule can be used to generate all files instead of having > one > # for each file type. Note that the sample.o has a dependency on the > @@ -55,10 +55,10 @@ sample.o: sample.c sample_tracepoint.h > # lttng-gen-tp $< > > %.h: %.tp > - $(LTTNG_GEN_TP_PATH)lttng-gen-tp -o $@ $< > + $(PYTHON) $(LTTNG_GEN_TP_PATH)lttng-gen-tp -o $@ $< > > %.c: %.tp > - $(LTTNG_GEN_TP_PATH)lttng-gen-tp -o $@ $< > + $(PYTHON) $(LTTNG_GEN_TP_PATH)lttng-gen-tp -o $@ $< > > .PHONY: clean > clean: > > > What do you think? >
I agree that this is not the proper fix... Note that this script is not required to build lttng-ust. It will not be used during the build process if your host doesn't have a suitable Python version installed; it is only used to build one of the examples. Regards, Jérémie > Thank you! > Gerlando > > (*) As suggested by > http://redsymbol.net/articles/env-and-python-scripts-version/ > > > _______________________________________________ > lttng-dev mailing list > lttng-dev@lists.lttng.org > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- Jérémie Galarneau EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev