[libvirt] FreeBSD-8.3 build failure for amd64/i386, build archive included
Libvirt no longer builds on FreeBSD 8.3. I had brought this up awhile ago, but didn't have the resources to get the requested information. A fellow committer was able to build, and send me an archive of the complete build failure for analysis. Here is a link to build archive for investigation. http://people.freebsd.org/~jgh/files/libvirt_83amd64.tar.xz Please let me know if there is any information you need. Thanks! -jgh -- Jason Helfman | FreeBSD Committer jgh@FreeBSD.org | http://people.freebsd.org/~jgh | The Power to Serve
On 26.09.2013 00:37, Jason Helfman wrote:
Libvirt no longer builds on FreeBSD 8.3. I had brought this up awhile ago, but didn't have the resources to get the requested information. A fellow committer was able to build, and send me an archive of the complete build failure for analysis.
Here is a link to build archive for investigation. http://people.freebsd.org/~jgh/files/libvirt_83amd64.tar.xz
D'oh! 403 - Forbidden Michal
On Thu, Sep 26, 2013 at 12:24 AM, Michal Privoznik <mprivozn@redhat.com>wrote:
On 26.09.2013 00:37, Jason Helfman wrote:
Libvirt no longer builds on FreeBSD 8.3. I had brought this up awhile ago, but didn't have the resources to get the requested information. A fellow committer was able to build, and send me an archive of the complete build failure for analysis.
Here is a link to build archive for investigation. http://people.freebsd.org/~jgh/files/libvirt_83amd64.tar.xz
D'oh! 403 - Forbidden
Michal
Fixed. -jgh -- Jason Helfman | FreeBSD Committer jgh@FreeBSD.org | http://people.freebsd.org/~jgh | The Power to Serve
On 27.09.2013 08:49, Jason Helfman wrote:
On Thu, Sep 26, 2013 at 12:24 AM, Michal Privoznik <mprivozn@redhat.com <mailto:mprivozn@redhat.com>> wrote:
On 26.09.2013 00 <tel:26.09.2013%2000>:37, Jason Helfman wrote: > Libvirt no longer builds on FreeBSD 8.3. I had brought this up awhile > ago, but didn't have the resources to get the requested information. A > fellow committer was able to build, and send me an archive of the > complete build failure for analysis. > > Here is a link to build archive for investigation. > http://people.freebsd.org/~jgh/files/libvirt_83amd64.tar.xz
D'oh! 403 - Forbidden
Michal
Fixed.
-jgh
So, I've downloaded the archive, unpacked it (had to change the path to sed) and I see this error: make[3]: Entering directory `/home/zippy/work/tmp/a/libvirt-1.1.2/gnulib/lib' CC allocator.lo In file included from allocator.c:4:0: ./stdlib.h:76:8: error: redefinition of 'struct random_data' struct random_data ^ In file included from ./stdlib.h:36:0, from allocator.c:4: /usr/include/stdlib.h:349:8: note: originally defined here struct random_data ^ In file included from /usr/include/sys/types.h:220:0, from ./sys/types.h:27, from /usr/include/stdlib.h:320, from ./stdlib.h:36, from allocator.c:4: There are a few more but of the same nature. The problem is, gnulib's stdlib.h defines the struct random_data. And so does the system's /usr/include/stdlib.h. Unfortunately, I'm not that familiar with gnulib to fix the issue myself. Eric, any thoughts on this? Is it possible that your recent gnulib update has fixed this? Michal
On 09/27/2013 01:35 AM, Michal Privoznik wrote:
make[3]: Entering directory `/home/zippy/work/tmp/a/libvirt-1.1.2/gnulib/lib' CC allocator.lo In file included from allocator.c:4:0: ./stdlib.h:76:8: error: redefinition of 'struct random_data' struct random_data ^ In file included from ./stdlib.h:36:0, from allocator.c:4: /usr/include/stdlib.h:349:8: note: originally defined here struct random_data ^ In file included from /usr/include/sys/types.h:220:0, from ./sys/types.h:27, from /usr/include/stdlib.h:320, from ./stdlib.h:36, from allocator.c:4:
There are a few more but of the same nature. The problem is, gnulib's stdlib.h defines the struct random_data. And so does the system's /usr/include/stdlib.h. Unfortunately, I'm not that familiar with gnulib to fix the issue myself. Eric, any thoughts on this? Is it possible that your recent gnulib update has fixed this?
That implies a bug in gnulib; I'll see if I can get it fixed today; we'd need to update the gnulib submodule of libvirt to pull in the fix, so hopefully I can get it done in time before the rc2 build is cut. Can you show me the config.log output related to detecting whether 'struct random_data' exists? Is this a case of circular header inclusion on FreeBSD (that is, does <sys/types.h> try to recursively include <stdlib.h> to pick up the struct?) -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Fri, Sep 27, 2013 at 4:57 AM, Eric Blake <eblake@redhat.com> wrote:
On 09/27/2013 01:35 AM, Michal Privoznik wrote:
make[3]: Entering directory `/home/zippy/work/tmp/a/libvirt-1.1.2/gnulib/lib' CC allocator.lo In file included from allocator.c:4:0: ./stdlib.h:76:8: error: redefinition of 'struct random_data' struct random_data ^ In file included from ./stdlib.h:36:0, from allocator.c:4: /usr/include/stdlib.h:349:8: note: originally defined here struct random_data ^ In file included from /usr/include/sys/types.h:220:0, from ./sys/types.h:27, from /usr/include/stdlib.h:320, from ./stdlib.h:36, from allocator.c:4:
There are a few more but of the same nature. The problem is, gnulib's stdlib.h defines the struct random_data. And so does the system's /usr/include/stdlib.h. Unfortunately, I'm not that familiar with gnulib to fix the issue myself. Eric, any thoughts on this? Is it possible that your recent gnulib update has fixed this?
That implies a bug in gnulib; I'll see if I can get it fixed today; we'd need to update the gnulib submodule of libvirt to pull in the fix, so hopefully I can get it done in time before the rc2 build is cut. Can you show me the config.log output related to detecting whether 'struct random_data' exists? Is this a case of circular header inclusion on FreeBSD (that is, does <sys/types.h> try to recursively include <stdlib.h> to pick up the struct?)
-- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Should be available here: http://people.freebsd.org/~jgh/files/libvirt_83amd64.tar.xz -jgh -- Jason Helfman | FreeBSD Committer jgh@FreeBSD.org | http://people.freebsd.org/~jgh | The Power to Serve
On 09/27/2013 01:01 PM, Jason Helfman wrote:
On Fri, Sep 27, 2013 at 4:57 AM, Eric Blake <eblake@redhat.com> wrote:
On 09/27/2013 01:35 AM, Michal Privoznik wrote:
make[3]: Entering directory `/home/zippy/work/tmp/a/libvirt-1.1.2/gnulib/lib' CC allocator.lo In file included from allocator.c:4:0: ./stdlib.h:76:8: error: redefinition of 'struct random_data' struct random_data ^ In file included from ./stdlib.h:36:0, from allocator.c:4: /usr/include/stdlib.h:349:8: note: originally defined here struct random_data ^
Can you show me the config.log output related to detecting whether 'struct random_data' exists? Is this a case of circular header inclusion on FreeBSD (that is, does <sys/types.h> try to recursively include <stdlib.h> to pick up the struct?)
Should be available here: http://people.freebsd.org/~jgh/files/libvirt_83amd64.tar.xz
Thanks; looking through that, I see: configure:31404: checking for struct random_data configure:31404: cc -std=gnu99 -c -O2 -pipe -fno-strict-aliasing -D_THREAD_SAFE -D_THREAD_SAFE conftest.c >&5 conftest.c: In function 'main': conftest.c:346: error: invalid application of 'sizeof' to incomplete type 'struct random_data' ... | #include <stdlib.h> | #if HAVE_RANDOM_H | # include <random.h> | #endif | | | int | main () | { | if (sizeof (struct random_data)) So, what has to be included prior to <stdlib.h> for the forward declaration of struct random_data in that header to no longer be an incomplete type? Can you grep your system headers and find what all mentions struct random_data? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Sat, Sep 28, 2013 at 4:36 PM, Eric Blake <eblake@redhat.com> wrote:
On 09/27/2013 01:01 PM, Jason Helfman wrote:
On Fri, Sep 27, 2013 at 4:57 AM, Eric Blake <eblake@redhat.com> wrote:
On 09/27/2013 01:35 AM, Michal Privoznik wrote:
make[3]: Entering directory `/home/zippy/work/tmp/a/libvirt-1.1.2/gnulib/lib' CC allocator.lo In file included from allocator.c:4:0: ./stdlib.h:76:8: error: redefinition of 'struct random_data' struct random_data ^ In file included from ./stdlib.h:36:0, from allocator.c:4: /usr/include/stdlib.h:349:8: note: originally defined here struct random_data ^
Can you show me the config.log output related to detecting whether 'struct random_data' exists? Is this a case of circular header inclusion on FreeBSD (that is, does <sys/types.h> try to recursively include <stdlib.h> to pick up the struct?)
Should be available here: http://people.freebsd.org/~jgh/files/libvirt_83amd64.tar.xz
Thanks; looking through that, I see:
configure:31404: checking for struct random_data configure:31404: cc -std=gnu99 -c -O2 -pipe -fno-strict-aliasing -D_THREAD_SAFE -D_THREAD_SAFE conftest.c >&5 conftest.c: In function 'main': conftest.c:346: error: invalid application of 'sizeof' to incomplete type 'struct random_data' ...
| #include <stdlib.h> | #if HAVE_RANDOM_H | # include <random.h> | #endif | | | int | main () | { | if (sizeof (struct random_data))
So, what has to be included prior to <stdlib.h> for the forward declaration of struct random_data in that header to no longer be an incomplete type? Can you grep your system headers and find what all mentions struct random_data?
In looking through our 8.4 Branch, here are the results of digging the tree: crypto/openssh/pkcs11.h: unsigned char *random_data, crypto/heimdal/lib/hx509/ref/pkcs11.h: unsigned char *random_data, crypto/heimdal/lib/hx509/hxtool.c:random_data(void *opt, int argc, char **argv) sys/netinet/sctp_output.c: SCTP_READ_RANDOM(randp->random_data, random_len); sys/netinet/sctp_header.h: uint8_t random_data[]; Per another developer at FreeBSD, it seems to be a bug in 8.x branch and picking up something it shouldn't and was "fixed" by adding this to the configure environment: ac_cv_type_struct_random_data="" http://redports.org/~jgh/20130930154500-61365-148605/libvirt-1.1.2.log However the build still fails, but looks to be a more standard failure. Any more ideas on this? -jgh -- Jason Helfman | FreeBSD Committer jgh@FreeBSD.org | http://people.freebsd.org/~jgh | The Power to Serve
On 09/30/13 09:09, Jason Helfman wrote:
http://redports.org/~jgh/20130930154500-61365-148605/libvirt-1.1.2.log <http://redports.org/%7Ejgh/20130930154500-61365-148605/libvirt-1.1.2.log>
However the build still fails, but looks to be a more standard failure
"internal compiler error: Segmentation fault" is a standard failure? I dunno, perhaps you have a bad development host, or perhaps you're just living so far over the bleeding edge that even gnulib can't save you.
On 09/30/2013 10:09 AM, Jason Helfman wrote:
So, what has to be included prior to <stdlib.h> for the forward declaration of struct random_data in that header to no longer be an incomplete type? Can you grep your system headers and find what all mentions struct random_data?
In looking through our 8.4 Branch, here are the results of digging the tree:
crypto/openssh/pkcs11.h: unsigned char *random_data, crypto/heimdal/lib/hx509/ref/pkcs11.h: unsigned char *random_data, crypto/heimdal/lib/hx509/hxtool.c:random_data(void *opt, int argc, char **argv) sys/netinet/sctp_output.c: SCTP_READ_RANDOM(randp->random_data, random_len);
Not relevant.
sys/netinet/sctp_header.h: uint8_t random_data[];
Maybe relevant. Can this header be picked up by some include sequence of standard-only headers, such that using <stdlib.h> in isolation doesn't have a problem, but <stdlib.h> in combination with this header causes the problem?
Per another developer at FreeBSD, it seems to be a bug in 8.x branch and picking up something it shouldn't and was "fixed" by adding this to the configure environment: ac_cv_type_struct_random_data=""
Generally, Autoconf wants you to use 'ac_cv_type_struct_random_data=no', not blank. I don't know if using 'no' instead of a blank would resolve the compiler core dump you hit. Is there a mail archive where you were discussing this with the FreeBSD developers?
http://redports.org/~jgh/20130930154500-61365-148605/libvirt-1.1.2.log
Also, this build was on FreeBSD 8.4, although you reported the problem against FreeBSD 8.3. Let's get it resolved on one platform before bouncing around to another (at the moment, I only have a FreeBSD 8.2 environment for my own testing, so I'm not much help at the moment). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Mon, Sep 30, 2013 at 11:50 AM, Eric Blake <eblake@redhat.com> wrote:
On 09/30/2013 10:09 AM, Jason Helfman wrote:
So, what has to be included prior to <stdlib.h> for the forward declaration of struct random_data in that header to no longer be an incomplete type? Can you grep your system headers and find what all mentions struct random_data?
In looking through our 8.4 Branch, here are the results of digging the tree:
crypto/openssh/pkcs11.h: unsigned char *random_data, crypto/heimdal/lib/hx509/ref/pkcs11.h: unsigned char *random_data, crypto/heimdal/lib/hx509/hxtool.c:random_data(void *opt, int argc, char **argv) sys/netinet/sctp_output.c: SCTP_READ_RANDOM(randp->random_data, random_len);
Not relevant.
sys/netinet/sctp_header.h: uint8_t random_data[];
Maybe relevant. Can this header be picked up by some include sequence of standard-only headers, such that using <stdlib.h> in isolation doesn't have a problem, but <stdlib.h> in combination with this header causes the problem?
Per another developer at FreeBSD, it seems to be a bug in 8.x branch and picking up something it shouldn't and was "fixed" by adding this to the configure environment: ac_cv_type_struct_random_data=""
Generally, Autoconf wants you to use 'ac_cv_type_struct_random_data=no', not blank. I don't know if using 'no' instead of a blank would resolve the compiler core dump you hit. Is there a mail archive where you were discussing this with the FreeBSD developers?
http://redports.org/~jgh/20130930154500-61365-148605/libvirt-1.1.2.log
Also, this build was on FreeBSD 8.4, although you reported the problem against FreeBSD 8.3. Let's get it resolved on one platform before bouncing around to another (at the moment, I only have a FreeBSD 8.2 environment for my own testing, so I'm not much help at the moment).
-- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
It all uses the same branch of code, so it won't matter what version while you are still in 8.x, unless you are running 8.x STABLE, and not a RELEASE based branch. In working with a fellow developer, this came down to gcc bugs that were addressed in later versions of FreeBSD, but was not merged from CURRENT branch to 8.x. Here is a link to the fix that I will be committing at some point today. http://people.freebsd.org/~jgh/files/libvirt-84fix.diff Here are all the buildlogs, as well: http://redports.org/buildarchive/20130930180500-15801/ -jgh -- Jason Helfman | FreeBSD Committer jgh@FreeBSD.org | http://people.freebsd.org/~jgh | The Power to Serve
On Mon, Sep 30, 2013 at 2:27 PM, Jason Helfman <jgh@freebsd.org> wrote:
On Mon, Sep 30, 2013 at 11:50 AM, Eric Blake <eblake@redhat.com> wrote:
On 09/30/2013 10:09 AM, Jason Helfman wrote:
So, what has to be included prior to <stdlib.h> for the forward declaration of struct random_data in that header to no longer be an incomplete type? Can you grep your system headers and find what all mentions struct random_data?
In looking through our 8.4 Branch, here are the results of digging the tree:
crypto/openssh/pkcs11.h: unsigned char *random_data, crypto/heimdal/lib/hx509/ref/pkcs11.h: unsigned char *random_data, crypto/heimdal/lib/hx509/hxtool.c:random_data(void *opt, int argc, char **argv) sys/netinet/sctp_output.c: SCTP_READ_RANDOM(randp->random_data, random_len);
Not relevant.
sys/netinet/sctp_header.h: uint8_t random_data[];
Maybe relevant. Can this header be picked up by some include sequence of standard-only headers, such that using <stdlib.h> in isolation doesn't have a problem, but <stdlib.h> in combination with this header causes the problem?
Per another developer at FreeBSD, it seems to be a bug in 8.x branch and picking up something it shouldn't and was "fixed" by adding this to the configure environment: ac_cv_type_struct_random_data=""
Generally, Autoconf wants you to use 'ac_cv_type_struct_random_data=no', not blank. I don't know if using 'no' instead of a blank would resolve the compiler core dump you hit. Is there a mail archive where you were discussing this with the FreeBSD developers?
http://redports.org/~jgh/20130930154500-61365-148605/libvirt-1.1.2.log
Also, this build was on FreeBSD 8.4, although you reported the problem against FreeBSD 8.3. Let's get it resolved on one platform before bouncing around to another (at the moment, I only have a FreeBSD 8.2 environment for my own testing, so I'm not much help at the moment).
-- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
It all uses the same branch of code, so it won't matter what version while you are still in 8.x, unless you are running 8.x STABLE, and not a RELEASE based branch.
In working with a fellow developer, this came down to gcc bugs that were addressed in later versions of FreeBSD, but was not merged from CURRENT branch to 8.x.
Here is a link to the fix that I will be committing at some point today.
http://people.freebsd.org/~jgh/files/libvirt-84fix.diff
Here are all the buildlogs, as well: http://redports.org/buildarchive/20130930180500-15801/
-jgh
-- Jason Helfman | FreeBSD Committer jgh@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
What's the error you're getting with -Wmissing-include-dirs? We should be testing to see if gcc supports that and not using it if its not supported. Additionally, what version of gcc are you using in 8.x? We can probably whip up a quick patch to resolve this. As far as the struct random_data, I'll let Eric work on that since he's got a better understand and more context. -- Doug Goldstein
On Mon, Sep 30, 2013 at 7:04 PM, Doug Goldstein <cardoe@gentoo.org> wrote:
On Mon, Sep 30, 2013 at 11:50 AM, Eric Blake <eblake@redhat.com> wrote:
On 09/30/2013 10:09 AM, Jason Helfman wrote:
So, what has to be included prior to <stdlib.h> for the forward declaration of struct random_data in that header to no longer be an incomplete type? Can you grep your system headers and find what all mentions struct random_data?
In looking through our 8.4 Branch, here are the results of digging the tree:
crypto/openssh/pkcs11.h: unsigned char *random_data, crypto/heimdal/lib/hx509/ref/pkcs11.h: unsigned char *random_data, crypto/heimdal/lib/hx509/hxtool.c:random_data(void *opt, int argc,
char
**argv) sys/netinet/sctp_output.c: SCTP_READ_RANDOM(randp->random_data, random_len);
Not relevant.
sys/netinet/sctp_header.h: uint8_t random_data[];
Maybe relevant. Can this header be picked up by some include sequence of standard-only headers, such that using <stdlib.h> in isolation doesn't have a problem, but <stdlib.h> in combination with this header causes the problem?
Per another developer at FreeBSD, it seems to be a bug in 8.x branch
and
picking up something it shouldn't and was "fixed" by adding this to
On Mon, Sep 30, 2013 at 2:27 PM, Jason Helfman <jgh@freebsd.org> wrote: the
configure environment: ac_cv_type_struct_random_data=""
Generally, Autoconf wants you to use 'ac_cv_type_struct_random_data=no', not blank. I don't know if using 'no' instead of a blank would resolve the compiler core dump you hit. Is there a mail archive where you were discussing this with the FreeBSD developers?
http://redports.org/~jgh/20130930154500-61365-148605/libvirt-1.1.2.log
Also, this build was on FreeBSD 8.4, although you reported the problem against FreeBSD 8.3. Let's get it resolved on one platform before bouncing around to another (at the moment, I only have a FreeBSD 8.2 environment for my own testing, so I'm not much help at the moment).
-- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
It all uses the same branch of code, so it won't matter what version while you are still in 8.x, unless you are running 8.x STABLE, and not a RELEASE based branch.
In working with a fellow developer, this came down to gcc bugs that were addressed in later versions of FreeBSD, but was not merged from CURRENT branch to 8.x.
Here is a link to the fix that I will be committing at some point today.
http://people.freebsd.org/~jgh/files/libvirt-84fix.diff
Here are all the buildlogs, as well: http://redports.org/buildarchive/20130930180500-15801/
-jgh
What's the error you're getting with -Wmissing-include-dirs? We should be testing to see if gcc supports that and not using it if its not supported. Additionally, what version of gcc are you using in 8.x? We can probably whip up a quick patch to resolve this.
These were bugs associated with the version of gcc in the 8.x branch, that were supposedly fixed in later RELEASE versions (ie. 9.x, 10.x). However, these fixes were not merged back into the 8.x branch, is my understanding. Here is a link to the log that has the error when using missing-include-dirs: https://redports.org/~jgh/20130930162300-20190-148614/libvirt-1.1.2.log My understanding is that we've been ripping this out of a number of gnome related ports due to the same failure. However, a patched gcc has resolved this for the x-STABLE branches, other than 8 :) In looking through our svn respository: http://svnweb.freebsd.org/base/release/8.4.0/gnu/usr.bin/cc/cc/Makefile?view... Seems we are at version GCC 4.2 as r169718 http://svnweb.freebsd.org/base?view=revision&revision=169718
As far as the struct random_data, I'll let Eric work on that since he's got a better understand and more context.
Great, thanks! -jgh -- Jason Helfman | FreeBSD Committer jgh@FreeBSD.org | http://people.freebsd.org/~jgh | The Power to Serve
participants (5)
-
Doug Goldstein -
Eric Blake -
Jason Helfman -
Michal Privoznik -
Paul Eggert