[libvirt] FreeBSD, no gcc present libvirt build issue
Hello, There is an initiative at FreeBSD in removing gcc from base system and using CLANG. That being said, we are trying to resolve issues of ports that can't build without gcc. Libvirt fell into this group, and are curious if anyone has any ideas on why this breakage would occur. Here is a link to the buildlog: http://pb2.nyi.freebsd.org/bulk/nogcc-default/2013-08-26_21h09m25s/logs/errors/libvirt-1.1.1.log Thanks very much! -jgh -- Jason Helfman | FreeBSD Committer j...@freebsd.org | http://people.freebsd.org/~jgh | The Power to Serve -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] FreeBSD, no gcc present libvirt build issue
On 08/29/2013 08:58 AM, Jason Helfman wrote:
Hello,
There is an initiative at FreeBSD in removing gcc from base system and
using CLANG. That being said, we are trying to resolve issues of ports that
can't build without gcc. Libvirt fell into this group, and are curious if
anyone has any ideas on why this breakage would occur.
Here is a link to the buildlog:
http://pb2.nyi.freebsd.org/bulk/nogcc-default/2013-08-26_21h09m25s/logs/errors/libvirt-1.1.1.log
The relevant section:
util/virrandom.c:75:1: error: bit-field '_gl_verify_error_if_negative'
has negative width (-1)
verify(((RAND_MAX + 1U) RAND_MAX) == 0);
^
../gnulib/lib/verify.h:251:19: note: expanded from macro 'verify'
#define verify(R) _GL_VERIFY (R, verify ( #R ))
^
../gnulib/lib/verify.h:211:8: note: expanded from macro '_GL_VERIFY'
[_GL_VERIFY_TRUE (R, DIAGNOSTIC)]
^
../gnulib/lib/verify.h:176:15: note: expanded from macro '_GL_VERIFY_TRUE'
(!!sizeof (_GL_VERIFY_TYPE (R, DIAGNOSTIC)))
^
../gnulib/lib/verify.h:196:27: note: expanded from macro '_GL_VERIFY_TYPE'
struct { unsigned int _gl_verify_error_if_negative: (R) ? 1 : -1; }
^
1 error generated.
gmake[3]: *** [libvirt_util_la-virrandom.lo] Error 1
What does RAND_MAX expand to?
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] FreeBSD, no gcc present libvirt build issue
On Thu, Aug 29, 2013 at 8:08 AM, Eric Blake ebl...@redhat.com wrote:
On 08/29/2013 08:58 AM, Jason Helfman wrote:
Hello,
There is an initiative at FreeBSD in removing gcc from base system and
using CLANG. That being said, we are trying to resolve issues of ports
that
can't build without gcc. Libvirt fell into this group, and are curious if
anyone has any ideas on why this breakage would occur.
Here is a link to the buildlog:
http://pb2.nyi.freebsd.org/bulk/nogcc-default/2013-08-26_21h09m25s/logs/errors/libvirt-1.1.1.log
The relevant section:
util/virrandom.c:75:1: error: bit-field '_gl_verify_error_if_negative'
has negative width (-1)
verify(((RAND_MAX + 1U) RAND_MAX) == 0);
^
../gnulib/lib/verify.h:251:19: note: expanded from macro 'verify'
#define verify(R) _GL_VERIFY (R, verify ( #R ))
^
../gnulib/lib/verify.h:211:8: note: expanded from macro '_GL_VERIFY'
[_GL_VERIFY_TRUE (R, DIAGNOSTIC)]
^
../gnulib/lib/verify.h:176:15: note: expanded from macro '_GL_VERIFY_TRUE'
(!!sizeof (_GL_VERIFY_TYPE (R, DIAGNOSTIC)))
^
../gnulib/lib/verify.h:196:27: note: expanded from macro '_GL_VERIFY_TYPE'
struct { unsigned int _gl_verify_error_if_negative: (R) ? 1 : -1; }
^
1 error generated.
gmake[3]: *** [libvirt_util_la-virrandom.lo] Error 1
What does RAND_MAX expand to?
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
stdlib.h:#defineRAND_MAX0x7fff
-jgh
--
Jason Helfman | FreeBSD Committer
j...@freebsd.org | http://people.freebsd.org/~jgh | The Power to Serve
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] FreeBSD, no gcc present libvirt build issue
On Thu, Aug 29, 2013 at 8:33 AM, Jason Helfman j...@freebsd.org wrote:
On Thu, Aug 29, 2013 at 8:08 AM, Eric Blake ebl...@redhat.com wrote:
On 08/29/2013 08:58 AM, Jason Helfman wrote:
Hello,
There is an initiative at FreeBSD in removing gcc from base system and
using CLANG. That being said, we are trying to resolve issues of ports
that
can't build without gcc. Libvirt fell into this group, and are curious
if
anyone has any ideas on why this breakage would occur.
Here is a link to the buildlog:
http://pb2.nyi.freebsd.org/bulk/nogcc-default/2013-08-26_21h09m25s/logs/errors/libvirt-1.1.1.log
The relevant section:
util/virrandom.c:75:1: error: bit-field '_gl_verify_error_if_negative'
has negative width (-1)
verify(((RAND_MAX + 1U) RAND_MAX) == 0);
^
../gnulib/lib/verify.h:251:19: note: expanded from macro 'verify'
#define verify(R) _GL_VERIFY (R, verify ( #R ))
^
../gnulib/lib/verify.h:211:8: note: expanded from macro '_GL_VERIFY'
[_GL_VERIFY_TRUE (R, DIAGNOSTIC)]
^
../gnulib/lib/verify.h:176:15: note: expanded from macro '_GL_VERIFY_TRUE'
(!!sizeof (_GL_VERIFY_TYPE (R, DIAGNOSTIC)))
^
../gnulib/lib/verify.h:196:27: note: expanded from macro '_GL_VERIFY_TYPE'
struct { unsigned int _gl_verify_error_if_negative: (R) ? 1 : -1; }
^
1 error generated.
gmake[3]: *** [libvirt_util_la-virrandom.lo] Error 1
What does RAND_MAX expand to?
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
stdlib.h:#defineRAND_MAX0x7fff
-jgh
And on our current head release (10) it is this:
#define RAND_MAX0x7ffd
Sorry for the double-mail.
-jgh
--
Jason Helfman | FreeBSD Committer
j...@freebsd.org | http://people.freebsd.org/~jgh | The Power to Serve
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] FreeBSD, no gcc present libvirt build issue
On 08/29/2013 09:35 AM, Jason Helfman wrote: stdlib.h:#defineRAND_MAX0x7fff Good. -jgh And on our current head release (10) it is this: #define RAND_MAX0x7ffd Huh? Why is this not 2**n-1? That violates assumptions we have made, and is WHY your compile failed. It has nothing to do with clang vs. gcc (both compilers would fail), it has to do with your changed system header resulting in violating assumptions that hold in ALL OTHER IMPLEMENTATIONS, that random numbers are evenly distributed within a range of a power of 2. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] FreeBSD, no gcc present libvirt build issue
On 08/29/2013 09:43 AM, Eric Blake wrote: On 08/29/2013 09:35 AM, Jason Helfman wrote: stdlib.h:#defineRAND_MAX0x7fff Good. -jgh And on our current head release (10) it is this: #define RAND_MAX0x7ffd Huh? Why is this not 2**n-1? That violates assumptions we have made, and is WHY your compile failed. It has nothing to do with clang vs. gcc (both compilers would fail), it has to do with your changed system header resulting in violating assumptions that hold in ALL OTHER IMPLEMENTATIONS, that random numbers are evenly distributed within a range of a power of 2. http://lists.freebsd.org/pipermail/svn-src-head/2013-July/049076.html makes it look like the reduction in range was _intentional_? Yuck. A non-power-of-2 random generator adds needless complexity to the user. I think I can fix libvirt to work around the boneheaded decision; basically, since we cannot trust the full range of random_r to be evenly distributed, I will have to tweak libvirt's call to truncate every call to random_r to a subset of bits that are more likely to be evenly distributed (maybe by shifting off the most- and least-significant bits returned, and only using 28 instead of 31 bits of randomness per call). But I would MUCH rather prefer that FreeBSD revisit their decision, and guarantee that random output be evenly distributed across the full 31 bits to begin with. I also intend to open a bug against POSIX to request that RAND_MAX be required to be 2**n-1, rather than relying on the assumption that everyone so far, until FreeBSD 10, has happened to meet that requirement. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] FreeBSD, no gcc present libvirt build issue
On Thu, Aug 29, 2013 at 09:52:52AM -0600, Eric Blake wrote: On 08/29/2013 09:43 AM, Eric Blake wrote: On 08/29/2013 09:35 AM, Jason Helfman wrote: stdlib.h:#defineRAND_MAX0x7fff Good. -jgh And on our current head release (10) it is this: #define RAND_MAX0x7ffd Huh? Why is this not 2**n-1? That violates assumptions we have made, and is WHY your compile failed. It has nothing to do with clang vs. gcc (both compilers would fail), it has to do with your changed system header resulting in violating assumptions that hold in ALL OTHER IMPLEMENTATIONS, that random numbers are evenly distributed within a range of a power of 2. http://lists.freebsd.org/pipermail/svn-src-head/2013-July/049076.html makes it look like the reduction in range was _intentional_? Yuck. A non-power-of-2 random generator adds needless complexity to the user. I think I can fix libvirt to work around the boneheaded decision; basically, since we cannot trust the full range of random_r to be evenly distributed, I will have to tweak libvirt's call to truncate every call to random_r to a subset of bits that are more likely to be evenly distributed (maybe by shifting off the most- and least-significant bits returned, and only using 28 instead of 31 bits of randomness per call). But I would MUCH rather prefer that FreeBSD revisit their decision, and guarantee that random output be evenly distributed across the full 31 bits to begin with. Since gnulib has a working random_r() function can we just make gnulib replace the boneheaded freebsd impl ? I also intend to open a bug against POSIX to request that RAND_MAX be required to be 2**n-1, rather than relying on the assumption that everyone so far, until FreeBSD 10, has happened to meet that requirement. 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] FreeBSD, no gcc present libvirt build issue
On 08/29/2013 09:52 AM, Eric Blake wrote: #define RAND_MAX0x7ffd Huh? Why is this not 2**n-1? That violates assumptions we have made, and is WHY your compile failed. It has nothing to do with clang vs. gcc (both compilers would fail), it has to do with your changed system header resulting in violating assumptions that hold in ALL OTHER IMPLEMENTATIONS, that random numbers are evenly distributed within a range of a power of 2. http://lists.freebsd.org/pipermail/svn-src-head/2013-July/049076.html makes it look like the reduction in range was _intentional_? Yuck. A non-power-of-2 random generator adds needless complexity to the user. I also intend to open a bug against POSIX to request that RAND_MAX be required to be 2**n-1, rather than relying on the assumption that everyone so far, until FreeBSD 10, has happened to meet that requirement. http://austingroupbugs.net/view.php?id=743 -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] FreeBSD, no gcc present libvirt build issue
On 08/29/2013 10:03 AM, Daniel P. Berrange wrote: I think I can fix libvirt to work around the boneheaded decision; basically, since we cannot trust the full range of random_r to be evenly distributed, I will have to tweak libvirt's call to truncate every call to random_r to a subset of bits that are more likely to be evenly distributed (maybe by shifting off the most- and least-significant bits returned, and only using 28 instead of 31 bits of randomness per call). But I would MUCH rather prefer that FreeBSD revisit their decision, and guarantee that random output be evenly distributed across the full 31 bits to begin with. Since gnulib has a working random_r() function can we just make gnulib replace the boneheaded freebsd impl ? Huh - the glibc man pages state that random_r returns RAND_MAX bits. random_r is a glibc extension: POSIX only requires rand(), rand_r(), and random(); but even with random(), POSIX has no requirements that it be related to RAND_MAX - so the fact that glibc equates random()/random_r() with RAND_MAX is also a glibc extension. I guess that means we should't be worrying about RAND_MAX in the first place, as it is tied to the (potentially algorithmically weaker) rand(), and need not have any bearing on the fact that we already use gnulib's random_r(). I'll play around with a patch. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] FreeBSD, no gcc present libvirt build issue
On 08/29/2013 10:33 AM, Eric Blake wrote: Since gnulib has a working random_r() function can we just make gnulib replace the boneheaded freebsd impl ? Huh - the glibc man pages state that random_r returns RAND_MAX bits. random_r is a glibc extension: POSIX only requires rand(), rand_r(), and random(); but even with random(), POSIX has no requirements that it be related to RAND_MAX - so the fact that glibc equates random()/random_r() with RAND_MAX is also a glibc extension. I guess that means we should't be worrying about RAND_MAX in the first place, as it is tied to the (potentially algorithmically weaker) rand(), and need not have any bearing on the fact that we already use gnulib's random_r(). I'll play around with a patch. As it is, POSIX recommends the use of drand48() and friends for multithreaded apps, not random() (where lrand48() would match precisely with a RAND_MAX of 0x7fff); but that's because POSIX lacks random_r(). But since gnulib lacks [dl]rand48(), I still think libvirt is still better off sticking with random_r(), and just avoiding the red herring of a potentially unrelated RAND_MAX. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] FreeBSD, no gcc present libvirt build issue
On Thu, Aug 29, 2013 at 9:42 AM, Eric Blake ebl...@redhat.com wrote: On 08/29/2013 10:33 AM, Eric Blake wrote: Since gnulib has a working random_r() function can we just make gnulib replace the boneheaded freebsd impl ? Huh - the glibc man pages state that random_r returns RAND_MAX bits. random_r is a glibc extension: POSIX only requires rand(), rand_r(), and random(); but even with random(), POSIX has no requirements that it be related to RAND_MAX - so the fact that glibc equates random()/random_r() with RAND_MAX is also a glibc extension. I guess that means we should't be worrying about RAND_MAX in the first place, as it is tied to the (potentially algorithmically weaker) rand(), and need not have any bearing on the fact that we already use gnulib's random_r(). I'll play around with a patch. As it is, POSIX recommends the use of drand48() and friends for multithreaded apps, not random() (where lrand48() would match precisely with a RAND_MAX of 0x7fff); but that's because POSIX lacks random_r(). But since gnulib lacks [dl]rand48(), I still think libvirt is still better off sticking with random_r(), and just avoiding the red herring of a potentially unrelated RAND_MAX. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org This is outside of my expertise at this point, but here is the discussion thread regarding this on a FreeBSD mailing list: http://lists.freebsd.org/pipermail/freebsd-current/2013-August/044084.html Thanks! -jgh -- Jason Helfman | FreeBSD Committer j...@freebsd.org | http://people.freebsd.org/~jgh | The Power to Serve -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
