Bug 64065

Summary: sw_python fails because configure picks up python 2.7 as PYTHON_FOR_BUILD
Product: LibreOffice Reporter: Rene Engelhard <rene>
Component: WriterAssignee: Michael Stahl (allotropia) <michael.stahl>
Status: RESOLVED FIXED    
Severity: normal CC: jmadero.dev, michael.stahl
Priority: medium    
Version: 4.1.0.0.alpha0+ Master   
Hardware: All   
OS: Linux (All)   
Whiteboard:
Crash report or crash signature: Regression By:

Description Rene Engelhard 2013-04-29 22:52:33 UTC
I just tried to build current master in my packaging env. Whcih points PYTHON, PYTHON_CFLAGS and PYTHON_LIBS to python3.3 and its libs as Debians default python is (and never will be, I fear, I guess that will stay python3..) 2.7.

Now autoconf seems to be trying to be smart but of course isn't and does the following:

checking for python... /usr/bin/python
checking for python version... (cached) 3.3

when checking for the PYTHON_FOR_BUILD which in turn means sw_python fails with
a syntax error here:

File 
"/home/rene/LibreOffice/master/core/unotest/source/python/org/libreoffice/unotest.py
print("starting soffice ... ", end="")

IIRC (and if I read http://docs.python.org/dev/howto/pyporting.html correctly) this is easily fixable by

diff --git a/unotest/source/python/org/libreoffice/unotest.py b/unotest/source/p
index 3ec016a..80bafbc 100644
--- a/unotest/source/python/org/libreoffice/unotest.py
+++ b/unotest/source/python/org/libreoffice/unotest.py
@@ -13,6 +13,8 @@ import uuid
 import argparse
 import os
 
+from __future__ import print_function
+
 try:
     import pyuno
     import uno

but it seems to be the check is broken... (need to workaround autoconf by forcing a non-cache value?)
Comment 1 Rene Engelhard 2013-04-29 23:04:04 UTC
the relevant parts of confing_host.mk
export PYTHON_CFLAGS=$(gb_SPACE)-I/usr/include/python3.3m -I/usr/include/x86_64-linux-gnu/python3.3m  
export PYTHON_FOR_BUILD=/usr/bin/python
export PYTHON_LIBS=$(gb_SPACE)-lpython3.3m  
export PYTHON_VERSION=3.3
export PYTHON_VERSION_MAJOR=
export PYTHON_VERSION_MINOR=

Yeah, I could also set PYTHON_FOR_BUILD for configure, but...

Note that if this isn't fixed we'll have fun on Debian/Ubuntu; their /usr/bin/python probably will never (at least in some forseeable future) point to python3, but /usr/bin/python3 will,
Comment 2 Rene Engelhard 2013-04-29 23:07:13 UTC
mst: David says you worked on this?
Comment 3 Rene Engelhard 2013-04-29 23:16:59 UTC
ok, with that iport (at the right place..) this doesn't seem to work either way:

ImportError: dynamic module does not define init function (initpyuno)
Comment 4 Joel Madero 2013-04-30 04:13:19 UTC
rene - marking as NEW because it's you ;) no need to confirm, you can prioritize wherever you think is appropriate.
Comment 5 Michael Stahl (allotropia) 2013-04-30 09:20:13 UTC
i tried to prevent this problem with b9e6bd790f99b9018ea0a594cca8efcb1709c5e7
"configure: try to make all PYTHON variables point to the same thing"

but evidently i suck and it doesn't work :)
Comment 7 Rene Engelhard 2013-05-13 20:29:02 UTC
yes, seems so:

$ PYTHON=python3.3 PYTHON_CFLAGS=`pkg-config --cflags python-3.3` PYTHON_LIBS=`pkg-config --libs python-3.3`
[...]
checking whether python3.3 version >= 2.5... yes
checking for python3.3 version... 3.3
checking for python3.3 platform... linux
checking for python3.3 script directory... ${prefix}/lib/python3/dist-packages
checking for python3.3 extension module directory... ${exec_prefix}/lib/python3/dist-packages
checking which Python to use for Pyuno... system
checking Python.h usability... yes
checking Python.h presence... yes
checking for Python.h... yes
checking for correct python library version... ok
[...]

$ grep PYTHON config_host.mk
export DISABLE_PYTHON=
export MINGW_PYTHON_EXE=
export PYTHON_CFLAGS=$(gb_SPACE)-I/usr/include/python3.3m -I/usr/include/x86_64-linux-gnu/python3.3m  
export PYTHON_FOR_BUILD=python3.3
export PYTHON_LIBS=$(gb_SPACE)-lpython3.3m  
export PYTHON_VERSION=
export PYTHON_VERSION_MAJOR=
export PYTHON_VERSION_MINOR=
export SYSTEM_PYTHON=YES