On Thu, Jan 07, 2010 at 08:36:25PM +0000, Daniel P. Berrange wrote:
On Thu, Jan 07, 2010 at 09:19:17PM +0100, Diego Elio ???Flameeyes???
Petten? wrote:
> Il giorno gio, 07/01/2010 alle 21.14 +0100, Jim Meyering ha scritto:
> >
> > The change below reverts 8838ee39ab1c2bb7fffe93bfda220692664e8be6,
> > so Diego, if your goal (with the reverted change) was more than to
> > avoid seemingly-unnecessary work, please tell us what it was.
>
> Well, to put it simply: you *cannot* both have the Python extension
> *and* disable shared libraries.
>
> --disable-shared tells libtool not to build any kind of shared object
> for the project; Python extensions are shared objects _only_.
>
> While you could avoid building libvirt.so (and just have libvirt.a) you
> cannot get Python extensions by just building libvirtmod.a.
>
> So basically --disable-shared --with-python would just produce an
> unusable output without my change, and produce a proper error condition
> with.
Agreed, if we want to support --disable-shared, then we can't pretend that
building python works. Either expect the error we already have which is
accurate, or make configure forcably disable the whole python build.
I assume Jim want to keep --disable-shared as a convenient way to
force libtool to generated binaries statically linked which is easier
when dealing with gdb. If that's the case what would be nice is to be
able to instruct auto*/libtool to build both libraries (where possible)
but force linking with static libraries. I have no idea how to do this
but that would be an useful option for autogen or configure.
Or just disable python if --disable-shared is passed that would be
fine too I think,
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit
http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library
http://libvirt.org/