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(a)redhat.com&gt; 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(a)redhat.com&gt; 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.

On Tue, Feb 19, 2013 at 2:54 PM, Jiri Denemark <jdenemar(a)redhat.com&gt; 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(a)redhat.com&gt; 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