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/e...

On Thu, Aug 29, 2013 at 8:08 AM, Eric Blake <eblake(a)redhat.com&gt; 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/e... > > 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:#define RAND_MAX 0x7fffffff -jgh

On 08/29/2013 09:35 AM, Jason Helfman wrote: >>> >> stdlib.h:#define RAND_MAX 0x7fffffff Good. >> >> -jgh >> > > And on our current head release (10) it is this: > > #define RAND_MAX 0x7ffffffd 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.

> 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 ?

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 0x7fffffff); 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