[libvirt] fix build failure with --disable-shared
Laine Stump noticed a failure to build with --disable-shared and found that removing the unconditional "-shared" option in python/Makefile.am would fix it. 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.
From 1de9c4a9a4175c9f1eb9302ad7fa9867e8a242a4 Mon Sep 17 00:00:00 2001 From: Laine Stump <laine@laine.org> Date: Thu, 7 Jan 2010 21:07:42 +0100 Subject: [PATCH] let "configure --disable-shared" work once again
Without this change, ./autogen.sh --disable-shared && make would evoke a "can not build a shared library" failure for libvirtmod.la. * python/Makefile.am (libvirtmod_la_LDFLAGS): Do not use -shared. --- python/Makefile.am | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/python/Makefile.am b/python/Makefile.am index 58c6729..04342b7 100644 --- a/python/Makefile.am +++ b/python/Makefile.am @@ -39,7 +39,7 @@ libvirtmod_la_SOURCES = libvirt-override.c typewrappers.c libvirt.c libvirt.h # need extra flags here libvirtmod_la_CFLAGS = @WARN_PYTHON_CFLAGS@ -libvirtmod_la_LDFLAGS = -module -avoid-version -shared -L$(top_builddir)/src/.libs \ +libvirtmod_la_LDFLAGS = -module -avoid-version -L$(top_builddir)/src/.libs \ @CYGWIN_EXTRA_LDFLAGS@ libvirtmod_la_LIBADD = $(mylibs) \ @CYGWIN_EXTRA_LIBADD@ @CYGWIN_EXTRA_PYTHON_LIBADD@ -- 1.6.6.425.g4dc2d
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. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
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.
But --disable-shared is useful, and your change broke it. As such, I can't see how you would be using --disable-shared. Does the proposed patch cause you any difficulty? If so, please tell us what/how, or propose an alternate patch.
Il giorno gio, 07/01/2010 alle 21.29 +0100, Jim Meyering ha scritto:
But --disable-shared is useful, and your change broke it.
On the usefulness of that I have generally a lot to say, but that's another topic.
As such, I can't see how you would be using --disable-shared.
Very simple: ./configure --disable-shared --without-python
Does the proposed patch cause you any difficulty? If so, please tell us what/how, or propose an alternate patch.
Without my patch you're building (and installing) an useless file with the default configuration (--enable-shared). And _pretending_ to build Python bindings (that will never work even the slightest) with the configuration you suggested (--disable-shared --with-python). Your really can't get it both ways. As Daniel (Berrange) said, the other option is to check whether shared libraries are enabled by libtool and either disable Python bindings or bail out earlier (configure rather than make) with the impossible combination of no-shared-libraries but-python-bindings. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
Diego Elio “Flameeyes” Pettenò wrote:
Il giorno gio, 07/01/2010 alle 21.29 +0100, Jim Meyering ha scritto:
But --disable-shared is useful, and your change broke it.
On the usefulness of that I have generally a lot to say, but that's another topic.
As such, I can't see how you would be using --disable-shared.
Very simple: ./configure --disable-shared --without-python
So your change forced all other users of --disable-shared to also configure with --without-python, but did not inform them of the new constraint. BTW, it also rendered build instructions in the FAQ invalid.
Does the proposed patch cause you any difficulty? If so, please tell us what/how, or propose an alternate patch.
Without my patch you're building (and installing) an useless file with
I use --disable-shared only when debugging (and then only sometimes), and certainly never install the result.
the default configuration (--enable-shared). And _pretending_ to build Python bindings (that will never work even the slightest) with the configuration you suggested (--disable-shared --with-python).
Your really can't get it both ways.
You're not considering my use case. So far, whenever I've used --disable-shared, whether python support is usable has been irrelevant to me.
As Daniel (Berrange) said, the other option is to check whether shared libraries are enabled by libtool and either disable Python bindings or bail out earlier (configure rather than make) with the impossible combination of no-shared-libraries but-python-bindings.
I'll make --disable-shared imply --without-python and silently override --with-python. Here's what I'll squash into the posted patch tomorrow: diff --git a/configure.in b/configure.in index 3f2f8ff..25df7a4 100644 --- a/configure.in +++ b/configure.in @@ -1813,6 +1813,10 @@ AC_ARG_WITH([qemu-group], AC_DEFINE_UNQUOTED([QEMU_USER], ["$QEMU_USER"], [QEMU user account]) AC_DEFINE_UNQUOTED([QEMU_GROUP], ["$QEMU_GROUP"], [QEMU group account]) +if test "$enable_shared:$with_python" = no:yes; then + AC_MSG_WARN([you've selected --disable-shared; so disabling python support]) + with_python=no +fi # Only COPYING.LIB is under version control, yet COPYING # is included as part of the distribution tarball.
Il giorno gio, 07/01/2010 alle 23.03 +0100, Jim Meyering ha scritto:
So your change forced all other users of --disable-shared to also configure with --without-python, but did not inform them of the new constraint. BTW, it also rendered build instructions in the FAQ invalid.
I don't want to sound defensive, but I *do* feel attacked a bit here, and I don't think I made any mistake in my patch and suggestion. If I did “force” users to configure properly, it was because the build system was working on a wrong assumption before. Sorry if I made it known that there is a bug there. As for the build instructions, I had to look them up now because I definitely hadn't looked at them; if I did, I would have et you know earlier about the fact that it's a *bad* advice to give. Why? Because I guess quite a few people interested in using libvirt would also be using virt-manager (especially since Daniel said that the XML files are not designed for user to edit, but for software to mangle) and that only works with proper Python bindings — and they are not generated with the suggested syntax in the FAQ. It actually can create quite a bad thing if the user tries to be smart and install the CVS (CVS? I thought it was developed in GIT) versions with make install after the configure, as the bindings and the virsh/libvirtd executables will be using very different libraries. Do I ask too much if next time, rather than noticing by chance that somebody wants to revert a change I proposed, you would reply to my own posting (which I watch more closely), letting me know it broke something? I'm pretty sure I can fix up things from there myself. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
Diego Elio “Flameeyes” Pettenò wrote:
Il giorno gio, 07/01/2010 alle 23.03 +0100, Jim Meyering ha scritto:
So your change forced all other users of --disable-shared to also configure with --without-python, but did not inform them of the new constraint. BTW, it also rendered build instructions in the FAQ invalid.
I don't want to sound defensive, but I *do* feel attacked a bit here, and I don't think I made any mistake in my patch and suggestion.
No attack intended. Merely explaining that your change does indeed disrupt certain workflows. Your change caused inconvenience for at least two developers I know about, and I took it upon myself to resolve the problem. If you had announced that --disable-shared must henceforth always be accompanied by --without-python, then that might have been ok, modulo the FAQ requiring an update. However, with the patch I posted, there's no need to change the FAQ or any habits/scripts.
If I did “force” users to configure properly,
The trouble is that your change had the undocumented side-effect of forcing people to change their previously-working-for-their-needs scripts.
it was because the build system was working on a wrong assumption before. Sorry if I made it known that there is a bug there.
Yes, you discovered a bug, and even sent in a patch. I do appreciate that.
As for the build instructions, I had to look them up now because I definitely hadn't looked at them; if I did, I would have et you know earlier about the fact that it's a *bad* advice to give.
Many programs can be configured with --disable-shared, and most of libvirt is still usable when configured that way. The bug was that the Python code was compiled in that case, and could have ended up being installed. However, do note that people familiar with the distribution guidelines warning against installing statically-linked libraries would know to avoid installing anything they had built that way.
Why? Because I guess quite a few people interested in using libvirt would also be using virt-manager (especially since Daniel said that the XML files are not designed for user to edit, but for software to mangle) and that only works with proper Python bindings — and they are not generated with the suggested syntax in the FAQ.
It actually can create quite a bad thing if the user tries to be smart and install the CVS (CVS? I thought it was developed in GIT) versions with make install after the configure, as the bindings and the virsh/libvirtd executables will be using very different libraries.
Do I ask too much if next time, rather than noticing by chance that somebody wants to revert a change I proposed, you would reply to my own posting (which I watch more closely), letting me know it broke something? I'm pretty sure I can fix up things from there myself.
I've learned that it is usually more efficient to propose a patch than to request one. I proposed to revert your change, because from my perspective it was obviously wrong. At the same time, I requested more information, because I assumed the change must have had more motivation than I could find in the mailing list and commit log. My proposing to revert your patch should not be taken as an insult or an offense, but rather as part of a request for additional justification. Once I had that, I was able to write a patch that solved both our problems. Just posted separately.
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. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
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@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
Il giorno gio, 07/01/2010 alle 22.23 +0100, Daniel Veillard ha scritto:
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.
Either of two: - pass -static option to LDFLAGS (it should _only_ work on the binaries but I'm not sure about it); - add an option that passes -all-static (libtool flag, _not_ linker flag) to only the LDFLAGS of the binaries; -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
On Thu, Jan 07, 2010 at 10:23:28PM +0100, Daniel Veillard wrote:
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.
What problems do shared libraries cause with GDB - I've never had any trouble with it at all - it 'just works' perfectly picking up any debuginfo packages from things we link against too. The only GDB issues I see are its inability to cope with -O2 optimized code.
Or just disable python if --disable-shared is passed that would be fine too I think,
I think that is the best option. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Il giorno ven, 08/01/2010 alle 11.16 +0000, Daniel P. Berrange ha scritto:
What problems do shared libraries cause with GDB - I've never had any trouble with it at all - it 'just works' perfectly picking up any debuginfo packages from things we link against too. The only GDB issues I see are its inability to cope with -O2 optimized code.
I think what they meant is not much related to shared libraries (which works pretty good with gdb) but with the handling of dynamically-linked executables and libtool: launching gdb ./virsh will not work, obviously; you either launch it directly (./.libs/virsh), but most people will forget to set the proper LD_LIBRARY_PATH entries and thus debug the installed copy of the libraries, or you pass through libtool, but most people don't know that. Alas, working around problems in all kind of ways is what brought us the doom that libtool complexity is. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
On Fri, Jan 08, 2010 at 12:21:44PM +0100, Diego Elio ???Flameeyes??? Petten? wrote:
Il giorno ven, 08/01/2010 alle 11.16 +0000, Daniel P. Berrange ha scritto:
What problems do shared libraries cause with GDB - I've never had any trouble with it at all - it 'just works' perfectly picking up any debuginfo packages from things we link against too. The only GDB issues I see are its inability to cope with -O2 optimized code.
I think what they meant is not much related to shared libraries (which works pretty good with gdb) but with the handling of dynamically-linked executables and libtool: launching gdb ./virsh will not work, obviously; you either launch it directly (./.libs/virsh), but most people will forget to set the proper LD_LIBRARY_PATH entries and thus debug the installed copy of the libraries, or you pass through libtool, but most people don't know that.
Hmm using --disable-shared is really not the right solution to that problem. For people that can't rememver the long libtool command name it is easy to create a wrapper $ cat ~/usr/bin/ltrun #!/bin/sh exec libtool --mode=execute "$@" Then you can just do this which isn't hard to remember or type ltrun gdb ./virsh Switching to static build to debug something is craziness, because it can and will change the behaviour of many memory-corruption related problems so that something you see fail with shared library build won't reproduce in the same way with a static build. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Diego Elio “Flameeyes” Pettenò -
Jim Meyering