python 2.7 vs. python 3.2 and compilation errors
Harry van der Wolf
On Ubuntu 12.1- Quantal I'm trying to compile the latest tip of hugin (6102:1f205fefbcd7 tip). I'm on Ubuntu 12.10 having a mix of python 2.7 and python 3.2. I need both and so does Ubuntu itself currently.
I started to use from my build directory the following command:
cmake .. -DBUILD_HSI:BOOL=ON -DSWIG_EXECUTABLE=/usr/bin/swig2.0 -DCMAKE_BUILD_TYPE=RelWithDebInfo
and got:
<snip>
-- Found PythonLibs: /usr/lib/python3.2/config/libpython3.2.so (found version "2.7.3")
-- Found SWIG: /usr/bin/swig2.0 (found suitable version "2.0.7", required is "2.0")
-- Using shared internal libraries
-- Python libs version: 2.7.3
-- Found PythonInterp: /usr/bin/python (found version "2.7.3")
-- Install Python libs into /usr/lib/python2.7/dist-packages
and on compilation I get:
Linking CXX executable hugin
../../hugin_script_interface/libhugin_python_interface.so.0.0: undefined reference to `PyInt_AsLong'
../../hugin_script_interface/libhugin_python_interface.so.0.0: undefined reference to `PyInstance_NewRaw'
../../hugin_script_interface/libhugin_python_interface.so.0.0: undefined reference to `PyString_AsString'
../../hugin_script_interface/libhugin_python_interface.so.0.0: undefined reference to `PyString_FromFormat'
../../hugin_script_interface/libhugin_python_interface.so.0.0: undefined reference to `PyString_ConcatAndDel'
../../hugin_script_interface/libhugin_python_interface.so.0.0: undefined reference to `PyString_FromString'
../../hugin_script_interface/libhugin_python_interface.so.0.0: undefined reference to `PyString_Format'
So it is mixing 2.7.3 with 3.2.
So according to the CMakeLists.txt I did:
cmake .. -DBUILD_HSI:BOOL=ON -DSWIG_EXECUTABLE=/usr/bin/swig2.0 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DPYTHON_INCLUDE_PATH="/usr/include/python2.7" -DPYTHON_INCLUDE_DIRS="/usr/lib/python2.7"
And got the exact same output from cmake as above and the build ended in the same compilation error(s).
Being such an extemely flexible guy I just switched to:
cmake .. -DBUILD_HSI:BOOL=ON -DSWIG_EXECUTABLE=/usr/bin/swig2.0 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DPYTHON_INCLUDE_PATH="/usr/include/python3.2" -DPYTHON_INCLUDE_DIRS="/usr/lib/python3.2"
Now I get
<snip>
-- Found PythonLibs: /usr/lib/python3.2/config/libpython3.2.so (found version "3.2.3")
-- Found SWIG: /usr/bin/swig2.0 (found suitable version "2.0.7", required is "2.0.4")
-- Using shared internal libraries
-- Python libs version: 3.2.3
-- Found PythonInterp: /usr/bin/python (found version "2.7.3")
-- Install Python libs into /usr/lib/python2.7/dist-packages
Again a mix and match and again the same compilation error meaning that 2.7.3 and 3.2 are still mixed up.
Is this a hugin bug or a cmake (FIND_PACKAGE(PythonLibs REQUIRED)) bug?
Or even worse: What am I doing wrong?
Harry
Bruno Postle
>
>Being such an extemely flexible guy I just switched to:
>cmake .. -DBUILD_HSI:BOOL=ON -DSWIG_EXECUTABLE=/usr/bin/swig2.0
>-DCMAKE_BUILD_TYPE=RelWithDebInfo
>-DPYTHON_INCLUDE_PATH="/usr/include/python3.2"
>-DPYTHON_INCLUDE_DIRS="/usr/lib/python3.2"
>2.7.3 and 3.2 are still mixed up.
>
>Is this a hugin bug or a cmake (FIND_PACKAGE(PythonLibs REQUIRED)) bug?
>Or even worse: What am I doing wrong?
fresh build from clean sources?
--
Bruno
Harry van der Wolf
Hi,
I always remove my CMakeCache.txt and in this case I completely emptied my build directory upon every new build (even though that takes more time).
But what do you mean with clean sources: A new download of the hg repository from sourceforge?
Like: hg clone http://hugin.hg.sourceforge.net:8000/hgroot/hugin/hugin hugin.hg
Would that help? I thought that that's the reason you use a build directory with cmake so that your source is never "touched"?
If it was as simple as removing either 2.7.3 or 3.2 I would already have done that, but as Ubuntu is migrating to 3.2 as it's new standard but is not fully there Ubuntu needs them both (and so do I by the way for a lot of programs).
Last night I built it without python (-DHSI=OFF) and that works fine of course, but that's not what I want.
Harry
Harry van der Wolf
In the automake/configure time you just did a "./configure --help" to get all the command flag options for your binary/library.
I have been searching far and wide for the same command for cmake, but I can't find.
Of course I can search the CMakeListst.txt to check all OPTIONs, but a neat and simple command would be so much easier.
Anyone who knows?
T. Modes
On 18 Jan., 19:15, Harry van der Wolf <hvdw...@gmail.com> wrote:
> So according to the CMakeLists.txt I did:
> cmake .. -DBUILD_HSI:BOOL=ON -DSWIG_EXECUTABLE=/usr/bin/swig2.0
> -DCMAKE_BUILD_TYPE=RelWithDebInfo
> -DPYTHON_INCLUDE_PATH="/usr/include/python2.7"
> -DPYTHON_INCLUDE_DIRS="/usr/lib/python2.7"
>
dirs will help ;-)
From FindPythonLibs
# PYTHON_LIBRARIES - path to the python library
# PYTHON_INCLUDE_PATH - path to where Python.h is found
(deprecated)
# PYTHON_INCLUDE_DIRS - path to where Python.h is found
But these paths are returned from FindPythonLibs.
Below the variables you will need are mentioned:
# If you'd like to specify the installation of Python to use, you
should modify
# the following cache variables:
# PYTHON_LIBRARY - path to the python library
# PYTHON_INCLUDE_DIR - path to where Python.h is found
Maybe you need also specify (FindPythonInterp)
# PYTHON_EXECUTABLE - path to the Python interpreter
to select the matching Python interpreter.
Thomas
T. Modes
easily (much much easily IMHO than on the command line).
Andreas Metzler
> On Ubuntu 12.1- Quantal I'm trying to compile the latest tip of hugin
> (6102:1f205fefbcd7 tip). I'm on Ubuntu 12.10 having a mix of python 2.7 and
> python 3.2. I need both and so does Ubuntu itself currently.
> I started to use from my build directory the following command:
> cmake .. -DBUILD_HSI:BOOL=ON -DSWIG_EXECUTABLE=/usr/bin/swig2.0
> -DCMAKE_BUILD_TYPE=RelWithDebInfo
> 2.7.3 and 3.2 are still mixed up.
For Debian's official packages we are using -DPythonLibs_FIND_VERSION=2.7
cu andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Harry van der Wolf
Below the variables you will need are mentioned:
# If you'd like to specify the installation of Python to use, you
should modify
# the following cache variables:
# PYTHON_LIBRARY - path to the python library
# PYTHON_INCLUDE_DIR - path to where Python.h is found
Maybe you need also specify (FindPythonInterp)
# PYTHON_EXECUTABLE - path to the Python interpreter
to select the matching Python interpreter.
Thomas
Thanks.
I now used:
cmake .. -DBUILD_HSI:BOOL=ON -DSWIG_EXECUTABLE=/usr/bin/swig2.0 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DPYTHON_INCLUDE_DIR="/usr/include/python2.7" -DPYTHON_LIBRARY="/usr/lib/libpython2.7.so.1" -DPYTHON_EXECUTABLE="/usr/bin/python2
This compiles fine.
The following also compiles and builds fine.
cmake .. -DBUILD_HSI:BOOL=ON -DSWIG_EXECUTABLE=/usr/bin/swig2.0 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DPYTHON_INCLUDE_DIR="/usr/include/python3.2" -DPYTHON_LIBRARY="/usr/lib/libpython3.2mu.so.1" -DPYTHON_EXECUTABLE="/usr/bin/python3"
Use the GUI. There is see all parameters/options and can change them
easily (much much easily IMHO than on the command line).
And then I need to leave to gui to run make: how weird!
I know you use cmake to configure and then make to make but why not a complete gui? Coming from Mac OS X, with a no doubt excellent user-friendly design, such a gui design decision is for me utter nonsence.
Anyway: the gui does the job correctly as well and when running make (actually make -j 3), the job gets done correctly.
Now that I've found the correct settings I will update the wiki (http://wiki.panotools.org/Hugin_Compiling_Ubuntu) for mixed environments like I curently have.
And then on to the stuff I did this for: updating the manual based on the latest gui status.
Harry
Kornel Benko
Am Samstag, 19. Januar 2013 um 15:20:03, schrieb Harry van der Wolf <hvd...@gmail.com>
> 2013/1/19 T. Modes <Thomas...@gmx.de>
>
> >
> > Below the variables you will need are mentioned:
> > # If you'd like to specify the installation of Python to use, you
> > should modify
> > # the following cache variables:
> > # PYTHON_LIBRARY - path to the python library
> > # PYTHON_INCLUDE_DIR - path to where Python.h is found
> >
> > Maybe you need also specify (FindPythonInterp)
> > # PYTHON_EXECUTABLE - path to the Python interpreter
> > to select the matching Python interpreter.
> >
> > Thomas
> >
>
>
> Thanks.
> I now used:
> cmake .. -DBUILD_HSI:BOOL=ON -DSWIG_EXECUTABLE=/usr/bin/swig2.0
> -DCMAKE_BUILD_TYPE=RelWithDebInfo
> -DPYTHON_INCLUDE_DIR="/usr/include/python2.7"
> -DPYTHON_LIBRARY="/usr/lib/libpython2.7.so.1"
> -DPYTHON_EXECUTABLE="/usr/bin/python2
I am curious, why '-DSWIG_EXECUTABLE=/usr/bin/swig2.0' is needed?
In CMakeLists.txt:341, we already search for swig
find_program(SWIG_EXECUTABLE NAMES swig2.0 swig)
> This compiles fine.
>
> The following also compiles and builds fine.
> cmake .. -DBUILD_HSI:BOOL=ON -DSWIG_EXECUTABLE=/usr/bin/swig2.0
> -DCMAKE_BUILD_TYPE=RelWithDebInfo
> -DPYTHON_INCLUDE_DIR="/usr/include/python3.2"
> -DPYTHON_LIBRARY="/usr/lib/libpython3.2mu.so.1"
> -DPYTHON_EXECUTABLE="/usr/bin/python3"
>
>
>
> 2013/1/19 T. Modes <Thomas...@gmx.de>
>
> > Use the GUI. There is see all parameters/options and can change them
> > easily (much much easily IMHO than on the command line).
> >
>
>
> I didn't even know there was a gui.
You cane even start the gui from the build-directory with:
#make edit_cache
> It doesn't give me options for PYTHON*
> unless I set the "advanced" checkbox. So after configure/generate the unix
> makefiles are generated.
> And then I need to leave to gui to run make: how weird!
The gui is only a wrapper for the cmake-call with all the params.
> I know you use cmake to configure and then make to make but why not a
> complete gui? Coming from Mac OS X, with a no doubt excellent user-friendly
> design, such a gui design decision is for me utter nonsence.
> Anyway: the gui does the job correctly as well and when running make
> (actually make -j 3), the job gets done correctly.
>
> Now that I've found the correct settings I will update the wiki (
> http://wiki.panotools.org/Hugin_Compiling_Ubuntu) for mixed environments
> like I curently have.
>
...
> Harry
Kornel
Harry van der Wolf
> I now used:> cmake .. -DBUILD_HSI:BOOL=ON -DSWIG_EXECUTABLE=/usr/bin/swig2.0
> -DCMAKE_BUILD_TYPE=RelWithDebInfo
> -DPYTHON_INCLUDE_DIR="/usr/include/python2.7"
> -DPYTHON_LIBRARY="/usr/lib/libpython2.7.so.1"
> -DPYTHON_EXECUTABLE="/usr/bin/python2
I am curious, why '-DSWIG_EXECUTABLE=/usr/bin/swig2.0' is needed?
In CMakeLists.txt:341, we already search for swig
find_program(SWIG_EXECUTABLE NAMES swig2.0 swig)
It isn't neccessary and neither is the -DBUILD_HSI:BOOL=ON as that's default on linuxes. It's still my old habit from Mac OS X where I had to specify almost every command flag and environment flag (like -DCMAKE_C_FLAGS_RELEASE:STRING="......") in existence when building with cmake.
> This compiles fine.
>
> The following also compiles and builds fine.
> cmake .. -DBUILD_HSI:BOOL=ON -DSWIG_EXECUTABLE=/usr/bin/swig2.0
> -DCMAKE_BUILD_TYPE=RelWithDebInfo
> -DPYTHON_INCLUDE_DIR="/usr/include/python3.2"
> -DPYTHON_LIBRARY="/usr/lib/libpython3.2mu.so.1"
> -DPYTHON_EXECUTABLE="/usr/bin/python3"
>
>
>
> 2013/1/19 T. Modes <Thomas...@gmx.de>
>
> > Use the GUI. There is see all parameters/options and can change them
> > easily (much much easily IMHO than on the command line).
> >
>
>
> I didn't even know there was a gui.
You cane even start the gui from the build-directory with:
#make edit_cache
I will dive into this cmake gui a little more. It might be THE way to build hugin on OS X with cmake instead of with XCode (and maybe not, but I will see).
Harry
Kornel Benko
Am Samstag, 19. Januar 2013 um 15:51:58, schrieb Harry van der Wolf <hvd...@gmail.com>
...
> > You cane even start the gui from the build-directory with:
> >
> > #make edit_cache
> >
> >
> >
> Thanks! I learn every day.
>
>
> I will dive into this cmake gui a little more. It might be THE way to build
> hugin on OS X with cmake instead of with XCode (and maybe not, but I will
> see).
>
> Harry
Since you are on ubuntu, you could also try
#cmake ... -DCPACK_BINARY_DEB:BOOL=ON ...
#make package
#sudo dpkg -i hugin-2012.1.0.6107-Linux.deb
Kornel
Harry van der Wolf
And that also works and is even simpler. Thanks as well.
(I lost count of all the compilation runs I've done by now)
Harry
Kornel Benko
Am Samstag, 19. Januar 2013 um 16:37:32, schrieb Harry van der Wolf <hvd...@gmail.com>
We could here change the search for PythonLibs at CMakeLists.txt:314 to
FIND_PACKAGE(PythonLibs 2.7 REQUIRED)
> And that also works and is even simpler. Thanks as well.
>
> (I lost count of all the compilation runs I've done by now)
:)
> Harry
>
Kornel
Harry van der Wolf
Am Samstag, 19. Januar 2013 um 16:37:32, schrieb Harry van der Wolf <hvd...@gmail.com>
We could here change the search for PythonLibs at CMakeLists.txt:314 to
FIND_PACKAGE(PythonLibs 2.7 REQUIRED)
Ubuntu is also working towards python 3.2 where they can and they want it to be the standard on the next release.
Harry
Kornel Benko
Am Samstag, 19. Januar 2013 um 16:51:44, schrieb Harry van der Wolf <hvd...@gmail.com>
> 2013/1/19 Kornel Benko <Kornel...@berlin.de>
>
> > **
Good point. We could make it depend on
find_program(PYTHON_EXE python3 python)
if(PYTHON_EXE_FOUND)
execute_process(COMMAND ${PYTHON_EXE} --version OUTPUT_VARIABLE P_VERS)
if(${P_VERS} MATCHES "Python \([0-9]+\\.[0-9]+[\\.0-9]*\)")
set(SEARCHP_VERS ${CMAKE_MATCH_1})
else()
set(SEARCHP_VERS)
endif()
find_package(PythonLibs ${SEARCHP_VERS} REQUIRED)
else()
message(FATAL_ERROR "Python required")
endif()
> Harry
Kornel
T. Modes
> Good point. We could make it depend on
> find_program(PYTHON_EXE python3 python)
>
installed 3.x will not be possible.
FindPythonLib and FindPythonInterpr handle both series. This is not
the case with your approach.
Also your approach will fail, if python is not in the path environment
variable. FindPythonIntpr handle also this case. So I think the
approach with the switch at the command line is working for the time
being.
@Harry
The CMake GUI can also generate project files for different IDE (MSVC,
KDevelop, CodeBlocks, XCode, ...) and also for makefile. So starting
the build process from the CMake GUI would be complicated and needed
to adopt to all different IDE. I don't know if all IDE support this
approach. So from this point of view I understand that they did not
add this feature to the GUI.
Thomas
Kornel Benko
Am Samstag, 19. Januar 2013 um 09:37:52, schrieb T. Modes <Thomas...@gmx.de>
> @Kornel
> >
> > Good point. We could make it depend on
> > find_program(PYTHON_EXE python3 python)
> >
>
> Then you prefer Python3 before 2.x. And selecting a 2.x serie with
> installed 3.x will not be possible.
Yes.
> FindPythonLib and FindPythonInterpr handle both series. This is not
> the case with your approach.
I don't know FindPythonInterpr. Ähm, now I see FindPythonInterp.cmake. This is nice.
So
find_package(PythonInterp REQUIRED) #gives PYTHON_EXECUTABLE + PYTHON_VERSION_STRING
find_package(PythonLibs ${PYTHON_VERSION_STRING} REQUIRED)
would do?
> Also your approach will fail, if python is not in the path environment
> variable. FindPythonIntpr handle also this case.
I don't see it. If python is not on system path also FindPythonIntp fails.
But it handles more cases, so I prefer it too.
> So I think the
> approach with the switch at the command line is working for the time
> being.
But the opportunity to set it now correctly is good IMHO. And setting
-DPYTHON_EXECUTABLE=... -DPythonLibs_FIND_VERSION=...
were still possible.
> @Harry
> The CMake GUI can also generate project files for different IDE (MSVC,
> KDevelop, CodeBlocks, XCode, ...) and also for makefile. So starting
> the build process from the CMake GUI would be complicated and needed
> to adopt to all different IDE. I don't know if all IDE support this
> approach. So from this point of view I understand that they did not
> add this feature to the GUI.
>
> Thomas
>
Kornel
T. Modes
> So
> find_package(PythonInterp REQUIRED) #gives PYTHON_EXECUTABLE + PYTHON_VERSION_STRING
> find_package(PythonLibs ${PYTHON_VERSION_STRING} REQUIRED)
> would do?
>
executable on Windows, where they are not needed for building ;-)
Thomas
Kornel Benko
Am Sonntag, 20. Januar 2013 um 00:59:59, schrieb T. Modes <Thomas...@gmx.de>
OK, so we should remove the code from src/hugin_script_interface/CMakeLists.txt:206
and patch the top most CMakeLists.txt
IF(BUILD_HSI)
...
if(WIN32)
find_package(PythonLibs REQUIRED)
else()
# Linux/MacOS
find_package(PythonInterp REQUIRED)
find_package(PythonLibs ${PYTHON_VERSION_STRING} REQUIRED)
endif()
...
endif()
> Thomas
Kornel