2:14 p.m.
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(a)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
2:19 p.m.
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/
2:29 p.m.
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.
2:51 p.m.
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/
4:03 p.m.
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.
4:21 p.m.
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/
2:06 a.m.
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.
2:36 p.m.
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 :|
3:23 p.m.
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/
3:29 p.m.
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/
5:16 a.m.
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 :|
5:21 a.m.
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/
5:53 a.m.
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 :|
5432
days inactive
5433
days old
12 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Diego Elio “Flameeyes” Pettenò -
Jim Meyering