[libvirt] building libvirt 1.0.2 without quite a few features - undefined reference to `curl_global_init'
Hi there I'm trying to rebuild libvirt 1.0.2 on various targets - mostyl f16 and f18 for now I've started from the specfile that I found in this source rpm here http://libvirt.org/sources/libvirt-1.0.2-1.fc17.src.rpm in which I've mostly added without clauses : %define _without_storage_disk true %define _without_storage_iscsi true %define _without_storage_fs true %define _without_storage_lvm true %define _without_polkit true %define _without_sasl true %define _without_audit true %define _without_netcf true %define _without_avahi true %define _without_sanlock true %define _without_xen true %define _without_qemu true %define _without_hyperv true %define _without_phyp true %define _without_esx true %define _without_libxl true when building with these settings though, I'm facing this undefined error below; this happened on both f16 and f18 I take it there must be something slightly broken in the specfile logic, if anybody had a hint on how to address this is would be much appreciated For one thing I don't know how to get the real sentence behind this 'CCLD' thing, so I could check if libcurl (which I believe should provide that symbol) is mentioned or not.. CCLD libvirtd /longbuildroot/BUILD/libvirt-1.0.2/src/.libs/libvirt.so: undefined reference to `curl_global_init' many thanks in anticipation -- Thierry
On Tue, Feb 19, 2013 at 04:28:48PM +0100, Thierry Parmentelat wrote:
Hi there
I'm trying to rebuild libvirt 1.0.2 on various targets - mostyl f16 and f18 for now
I've started from the specfile that I found in this source rpm here http://libvirt.org/sources/libvirt-1.0.2-1.fc17.src.rpm
in which I've mostly added without clauses :
%define _without_storage_disk true %define _without_storage_iscsi true %define _without_storage_fs true %define _without_storage_lvm true %define _without_polkit true %define _without_sasl true %define _without_audit true %define _without_netcf true %define _without_avahi true %define _without_sanlock true %define _without_xen true %define _without_qemu true %define _without_hyperv true %define _without_phyp true %define _without_esx true %define _without_libxl true
when building with these settings though, I'm facing this undefined error below; this happened on both f16 and f18 I take it there must be something slightly broken in the specfile logic, if anybody had a hint on how to address this is would be much appreciated For one thing I don't know how to get the real sentence behind this 'CCLD' thing, so I could check if libcurl (which I believe should provide that symbol) is mentioned or not..
CCLD libvirtd /longbuildroot/BUILD/libvirt-1.0.2/src/.libs/libvirt.so: undefined reference to `curl_global_init'
You need this fix commit 514b93061c11a4a61454458bcb2980a482185959 Author: Jiri Denemark <jdenemar@redhat.com> Date: Fri Feb 1 13:36:06 2013 +0100 build: Add libcurl dependency to libvirt_driver.la libvirt.c calls curl_global_init() if WITH_CURL is defined and thus it should be linked with libcurl. This fixes link failure in case neither xenapi nor esx driver is enabled (they are the only users of libcurl). Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Thanks ; this does help with the particular issue I had However I'm still not quite there yet and am receiving ... CCLD securityselinuxtest CCLD securityselinuxlabeltest /usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status Any idea with this one ? Thanks again for the help in any case -- Thierry On Feb 19, 2013, at 4:55 PM, Daniel P. Berrange wrote:
On Tue, Feb 19, 2013 at 04:28:48PM +0100, Thierry Parmentelat wrote:
Hi there
I'm trying to rebuild libvirt 1.0.2 on various targets - mostyl f16 and f18 for now
I've started from the specfile that I found in this source rpm here http://libvirt.org/sources/libvirt-1.0.2-1.fc17.src.rpm
in which I've mostly added without clauses :
%define _without_storage_disk true %define _without_storage_iscsi true %define _without_storage_fs true %define _without_storage_lvm true %define _without_polkit true %define _without_sasl true %define _without_audit true %define _without_netcf true %define _without_avahi true %define _without_sanlock true %define _without_xen true %define _without_qemu true %define _without_hyperv true %define _without_phyp true %define _without_esx true %define _without_libxl true
when building with these settings though, I'm facing this undefined error below; this happened on both f16 and f18 I take it there must be something slightly broken in the specfile logic, if anybody had a hint on how to address this is would be much appreciated For one thing I don't know how to get the real sentence behind this 'CCLD' thing, so I could check if libcurl (which I believe should provide that symbol) is mentioned or not..
CCLD libvirtd /longbuildroot/BUILD/libvirt-1.0.2/src/.libs/libvirt.so: undefined reference to `curl_global_init'
You need this fix
commit 514b93061c11a4a61454458bcb2980a482185959 Author: Jiri Denemark <jdenemar@redhat.com> Date: Fri Feb 1 13:36:06 2013 +0100
build: Add libcurl dependency to libvirt_driver.la
libvirt.c calls curl_global_init() if WITH_CURL is defined and thus it should be linked with libcurl. This fixes link failure in case neither xenapi nor esx driver is enabled (they are the only users of libcurl).
Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Tue, Feb 19, 2013 at 19:42:46 +0100, Thierry Parmentelat wrote:
Thanks ; this does help with the particular issue I had However I'm still not quite there yet and am receiving
... CCLD securityselinuxtest CCLD securityselinuxlabeltest /usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status
Any idea with this one ?
commit d6c8597046dfc6b94ef5d7bf0b9ffae725a9c104 Author: Jiri Denemark <jdenemar@redhat.com> Date: Wed Jan 30 16:44:06 2013 +0100 tests: Don't build securityselinuxlabeltest without qemu Sources for securityselinuxlabeltest are only defined if qemu driver is enabled so we should not try to build the test if qemu driver is disabled. Jirka
great,I can now build that stuff on f16 at least - Thanks !! On Feb 19, 2013, at 7:51 PM, Jiri Denemark wrote:
On Tue, Feb 19, 2013 at 19:42:46 +0100, Thierry Parmentelat wrote:
Thanks ; this does help with the particular issue I had However I'm still not quite there yet and am receiving
... CCLD securityselinuxtest CCLD securityselinuxlabeltest /usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status
Any idea with this one ?
commit d6c8597046dfc6b94ef5d7bf0b9ffae725a9c104 Author: Jiri Denemark <jdenemar@redhat.com> Date: Wed Jan 30 16:44:06 2013 +0100
tests: Don't build securityselinuxlabeltest without qemu
Sources for securityselinuxlabeltest are only defined if qemu driver is enabled so we should not try to build the test if qemu driver is disabled.
Jirka
On Tue, Feb 19, 2013 at 2:17 PM, Thierry Parmentelat <thierry.parmentelat@inria.fr> wrote:
great,I can now build that stuff on f16 at least - Thanks !!
On Feb 19, 2013, at 7:51 PM, Jiri Denemark wrote:
On Tue, Feb 19, 2013 at 19:42:46 +0100, Thierry Parmentelat wrote:
Thanks ; this does help with the particular issue I had However I'm still not quite there yet and am receiving
... CCLD securityselinuxtest CCLD securityselinuxlabeltest /usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status
Any idea with this one ?
commit d6c8597046dfc6b94ef5d7bf0b9ffae725a9c104 Author: Jiri Denemark <jdenemar@redhat.com> Date: Wed Jan 30 16:44:06 2013 +0100
tests: Don't build securityselinuxlabeltest without qemu
Sources for securityselinuxlabeltest are only defined if qemu driver is enabled so we should not try to build the test if qemu driver is disabled.
Jirka
FWIW, I keep the patchset that I push into Gentoo now in a bit friendlier place to access: http://git.cardoe.com/?p=libvirt.git;a=shortlog;h=refs/heads/v1.0.2-maint Due to Gentoo "supporting" each release of libvirt, we'll have a stable branch for every release that others are welcome to follow or look at or make suggestions to include. -- Doug Goldstein
On Tue, Feb 19, 2013 at 14:37:40 -0600, Doug Goldstein wrote:
FWIW, I keep the patchset that I push into Gentoo now in a bit friendlier place to access:
http://git.cardoe.com/?p=libvirt.git;a=shortlog;h=refs/heads/v1.0.2-maint
Due to Gentoo "supporting" each release of libvirt, we'll have a stable branch for every release that others are welcome to follow or look at or make suggestions to include.
Doug, any reason for not having them in upstream libvirt git? We already have maint branches for some releases, which happen to be the releases present in Fedora and the main reason for that is the people maintaining them are mostly interested in Fedora. But we encourage others that are interested in having maint branches for other releases to do so. And the nice thing about it is, that if an ugly bug that has been present in libvirt for a long time may be fixed in all maint branches at once even by people who are really interested in just some of them. Jirka
On Tue, Feb 19, 2013 at 2:54 PM, Jiri Denemark <jdenemar@redhat.com> wrote:
On Tue, Feb 19, 2013 at 14:37:40 -0600, Doug Goldstein wrote:
FWIW, I keep the patchset that I push into Gentoo now in a bit friendlier place to access:
http://git.cardoe.com/?p=libvirt.git;a=shortlog;h=refs/heads/v1.0.2-maint
Due to Gentoo "supporting" each release of libvirt, we'll have a stable branch for every release that others are welcome to follow or look at or make suggestions to include.
Doug, any reason for not having them in upstream libvirt git? We already have maint branches for some releases, which happen to be the releases present in Fedora and the main reason for that is the people maintaining them are mostly interested in Fedora. But we encourage others that are interested in having maint branches for other releases to do so. And the nice thing about it is, that if an ugly bug that has been present in libvirt for a long time may be fixed in all maint branches at once even by people who are really interested in just some of them.
Jirka
No reason not to. I'll gladly add them if people would like that. -- Doug Goldstein
Hi again Looks like I claimed victory quite a liitle bit too early ;-) So, on f16 with the set of features turned off, I could rpmbuild but ran into an issue when trying to yum-install libvirt, because it required libvirt-daemon-driver-interface looks like this interface rpm is not created in my case because I've turned off netcf, so I'm trying to work around this problem by re-enabling netcf, but if there's any other way I could go please let me know And, on f18, I'm still facing this issue here CCLD libvirtd /longbuildroot/BUILD/libvirt-1.0.2/src/.libs/libvirt.so: undefined reference to `curl_global_init' collect2: error: ld returned 1 exit status even though I have *double* checked that I have enabled the same patch that solved my problem on f16.... just in case that can be useful, here are the curl rpms that I have installed on my build box at the time of this problem [2013.02.20--lxc18] /build/BUILD/libvirt-1.0.2 # rpm -aq | grep curl curl-7.27.0-5.fc18.x86_64 libcurl-devel-7.27.0-5.fc18.x86_64 libcurl-7.27.0-5.fc18.x86_64 python-pycurl-7.19.0-12.fc18.x86_64 Many thanks -- Thierry On Feb 19, 2013, at 10:43 PM, Doug Goldstein wrote:
On Tue, Feb 19, 2013 at 2:54 PM, Jiri Denemark <jdenemar@redhat.com> wrote:
On Tue, Feb 19, 2013 at 14:37:40 -0600, Doug Goldstein wrote:
FWIW, I keep the patchset that I push into Gentoo now in a bit friendlier place to access:
http://git.cardoe.com/?p=libvirt.git;a=shortlog;h=refs/heads/v1.0.2-maint
Due to Gentoo "supporting" each release of libvirt, we'll have a stable branch for every release that others are welcome to follow or look at or make suggestions to include.
Doug, any reason for not having them in upstream libvirt git? We already have maint branches for some releases, which happen to be the releases present in Fedora and the main reason for that is the people maintaining them are mostly interested in Fedora. But we encourage others that are interested in having maint branches for other releases to do so. And the nice thing about it is, that if an ugly bug that has been present in libvirt for a long time may be fixed in all maint branches at once even by people who are really interested in just some of them.
Jirka
No reason not to. I'll gladly add them if people would like that.
-- Doug Goldstein
On Tue, Feb 19, 2013 at 15:43:57 -0600, Doug Goldstein wrote:
On Tue, Feb 19, 2013 at 2:54 PM, Jiri Denemark <jdenemar@redhat.com> wrote:
On Tue, Feb 19, 2013 at 14:37:40 -0600, Doug Goldstein wrote:
FWIW, I keep the patchset that I push into Gentoo now in a bit friendlier place to access:
http://git.cardoe.com/?p=libvirt.git;a=shortlog;h=refs/heads/v1.0.2-maint
Due to Gentoo "supporting" each release of libvirt, we'll have a stable branch for every release that others are welcome to follow or look at or make suggestions to include.
Doug, any reason for not having them in upstream libvirt git? We already have maint branches for some releases, which happen to be the releases present in Fedora and the main reason for that is the people maintaining them are mostly interested in Fedora. But we encourage others that are interested in having maint branches for other releases to do so. And the nice thing about it is, that if an ugly bug that has been present in libvirt for a long time may be fixed in all maint branches at once even by people who are really interested in just some of them.
Jirka
No reason not to. I'll gladly add them if people would like that.
Sure, just create v1.0.2-maint branch in upstream git repository and cherry-pick patches there. It's possible git won't let you push the branch, in which case let us know and we'll solve it. Jirka
Hi all I have 2 additional suggestions for a smoother build with 1.0.2 * I applied this change in my specfile: http://git.onelab.eu/?p=libvirt.git;a=commitdiff;h=184bc19ce855e1498f6775b71... otherwise like I reported already, I end up with a plain libvirt rpm that requires libvirt-daemon-driver-interface that the build does not produce * this patch here http://git.onelab.eu/?p=libvirt.git;a=blob;f=libcurl-daemon.patch;h=a13198e7... was required on f18 for me as well (this is similar to a change in src/Makefile.am that you guys had pointed me to in the first place) for that to kick in I also had to add 'autoreconf' before %configure in the specfile (I haven't tested with just he autoreconf, that might have been enough ?) IMHO I feel like this would make sense in mainstream, although I would not go as far as to claim that I captured the whole subtlety of that build :-) Thanks anyway for all the hints and help -- Thierry On Feb 20, 2013, at 4:57 PM, Jiri Denemark wrote:
On Tue, Feb 19, 2013 at 15:43:57 -0600, Doug Goldstein wrote:
On Tue, Feb 19, 2013 at 2:54 PM, Jiri Denemark <jdenemar@redhat.com> wrote:
On Tue, Feb 19, 2013 at 14:37:40 -0600, Doug Goldstein wrote:
FWIW, I keep the patchset that I push into Gentoo now in a bit friendlier place to access:
http://git.cardoe.com/?p=libvirt.git;a=shortlog;h=refs/heads/v1.0.2-maint
Due to Gentoo "supporting" each release of libvirt, we'll have a stable branch for every release that others are welcome to follow or look at or make suggestions to include.
Doug, any reason for not having them in upstream libvirt git? We already have maint branches for some releases, which happen to be the releases present in Fedora and the main reason for that is the people maintaining them are mostly interested in Fedora. But we encourage others that are interested in having maint branches for other releases to do so. And the nice thing about it is, that if an ugly bug that has been present in libvirt for a long time may be fixed in all maint branches at once even by people who are really interested in just some of them.
Jirka
No reason not to. I'll gladly add them if people would like that.
Sure, just create v1.0.2-maint branch in upstream git repository and cherry-pick patches there. It's possible git won't let you push the branch, in which case let us know and we'll solve it.
Jirka
On Thu, Feb 21, 2013 at 09:00:04 +0100, Thierry Parmentelat wrote:
Hi all
I have 2 additional suggestions for a smoother build with 1.0.2
* I applied this change in my specfile: http://git.onelab.eu/?p=libvirt.git;a=commitdiff;h=184bc19ce855e1498f6775b71... otherwise like I reported already, I end up with a plain libvirt rpm that requires libvirt-daemon-driver-interface that the build does not produce
* this patch here http://git.onelab.eu/?p=libvirt.git;a=blob;f=libcurl-daemon.patch;h=a13198e7... was required on f18 for me as well (this is similar to a change in src/Makefile.am that you guys had pointed me to in the first place) for that to kick in I also had to add 'autoreconf' before %configure in the specfile (I haven't tested with just he autoreconf, that might have been enough ?)
Oh right, if you add a patch for Makefile.am to a spec file, you need to set enable_autotools to 1 (no need to manually add a call to autoreconf since it's already there); look at lines 11-14 in the spec file.
IMHO I feel like this would make sense in mainstream, although I would not go as far as to claim that I captured the whole subtlety of that build :-)
Feel free to send patches to this list, that's the best way of discussing whether they fix something in the right way. Jirka
participants (4)
-
Daniel P. Berrange -
Doug Goldstein -
Jiri Denemark -
Thierry Parmentelat