[libvirt] Python script and extension module directory handling

Matthias Bolte matthias.bolte at googlemail.com
Fri Dec 11 23:47:46 UTC 2009


Commit 66137344feb488ea87b0d92f3c03844d9a7a7786 changed the Python
detection mechanism in configure. This results in a changed install
location for the Python bindings at least on Fedora 12 64bit systems.

For the explanation below I assume a Fedora 12 64bit systems, libvirt
is configured with prefix /usr and Python 2.6 is installed.

Before this commit libvirt.py and libvirtmod.so were installed to
/usr/lib64/python2.6/site-packages. After this commit both are
installed to /usr/lib/python2.6/site-packages. This is at least wrong
for libvirtmod.so, as it should be installed to
/usr/lib64/python2.6/site-packages on a 64bit system.

Before this commit pythondir was set manually to
/usr/lib64/python2.6/site-packages and python/Makefile.am contains
'python_LTLIBRARIES = libvirtmod.la' that results in installing
libvirtmod.so to pythondir.

AM_PATH_PYTHON defines two variables: pythondir and pyexecdir. But
according to the AM_PATH_PYTHON documentation [1] pythondir is the
directory where Python scripts should be installed.
/usr/lib/python2.6/site-packages in this case, because Python scripts
are not architecture dependent in general. pyexecdir is the directory
where Python extension modules (shared libraries) should be installed.
AM_PATH_PYTHON detects pyexecdir correctly as
/usr/lib64/python2.6/site-packages, but python/Makefile.am contains
'python_LTLIBRARIES = libvirtmod.la' that results in installing
libvirtmod.so to pythondir.

So python/Makefile.am must be changed:



diff --git a/python/Makefile.am b/python/Makefile.am
index 736631e..04342b7 100644
--- a/python/Makefile.am
+++ b/python/Makefile.am
@@ -32,7 +32,7 @@ mylibs = $(top_builddir)/src/libvirt.la

 all-local: libvirt.py

-python_LTLIBRARIES = libvirtmod.la
+pyexec_LTLIBRARIES = libvirtmod.la

 libvirtmod_la_SOURCES = libvirt-override.c typewrappers.c libvirt.c libvirt.h
 # Python <= 2.4 header files contain a redundant decl, hence we



Now libvirtmod.so is installed to the correct directory:
/usr/lib64/python2.6/site-packages

But libvirt.py gets installed to /usr/lib/python2.6/site-packages,
this is different from the installation directory before the commit.

A default Fedora 12 64bit installation has *.py files installed to
/usr/lib/python2.6/site-packages and
/usr/lib64/python2.6/site-packages. By looking at both directories the
policy it pretty obvious: Packages that are pure Python go to
/usr/lib/python2.6/site-packages and packages that are mixed (Python
and shared libraries) go completely to
/usr/lib64/python2.6/site-packages.

So we restore the behavior from before the commit completely by
applying this additional patch:



diff --git a/python/Makefile.am b/python/Makefile.am
index 736631e..04342b7 100644
--- a/python/Makefile.am
+++ b/python/Makefile.am
@@ -60,14 +60,14 @@ $(GENERATED): generated.stamp
 $(libvirtmod_la_OBJECTS): $(GENERATED)

 install-data-local:
-	$(mkinstalldirs) $(DESTDIR)$(pythondir)
-	@INSTALL@ -m 0644 libvirt.py $(DESTDIR)$(pythondir)
+	$(mkinstalldirs) $(DESTDIR)$(pyexecdir)
+	@INSTALL@ -m 0644 libvirt.py $(DESTDIR)$(pyexecdir)
 	$(mkinstalldirs) $(DESTDIR)$(DOCS_DIR)
 	@(for doc in $(DOCS) ; \
 	   do @INSTALL@ -m 0644 $$doc $(DESTDIR)$(DOCS_DIR) ; done)

 uninstall-local:
-	rm -f $(DESTDIR)$(pythondir)/libvirt.py
+	rm -f $(DESTDIR)$(pyexecdir)/libvirt.py

 CLEANFILES= $(GENERATED) generated.stamp



I discussed this with Daniel Veillard on IRC and there was some
confusion what the actual problem was and how to solve it, so I wanted
to recap it here.

Also thanks to Daniel Hokka Zakrisson, who gave the important hint
about pythondir vs pyexecdir on IRC.

[1] http://www.gnu.org/software/hello/manual/automake/Python.html

Matthias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-install-location-for-Python-bindings.diff
Type: text/x-diff
Size: 2568 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20091212/22d5b980/attachment-0001.bin>


More information about the libvir-list mailing list