Compile error when using Newlib with Xen project

29 views Asked by At

I'm attempting to compile Xen on Ubuntu 16.04 and have run into a vexing error:

configure:31808: error: cannot compute sizeof (unsigned short)
See `config.log' for more details.

Upon investigation, I found that the error originates from this conftest program:

typedef unsigned short ac__type_sizeof_;
static long int longval () { return (long int) (sizeof (ac__type_sizeof_)); }
static unsigned long int ulongval () { return (long int) (sizeof (ac__type_sizeof_)); }
#include <stdio.h>
#include <stdlib.h>
int
main ()
{
  
  FILE *f = fopen ("conftest.val", "w");
  if (! f)
    return 1;
  if (((long int) (sizeof (ac__type_sizeof_))) < 0)
    {
      long int i = longval ();
      if (i != ((long int) (sizeof (ac__type_sizeof_))))
    return 1;
      fprintf (f, "%ld\n", i);
    }
  else
    {
      unsigned long int i = ulongval ();
      if (i != ((long int) (sizeof (ac__type_sizeof_))))
    return 1;
      fprintf (f, "%lu\n", i);
    }
  return ferror (f) || fclose (f) != 0;

  return 0;
}

The above program is being compiled with the following command:

configure:31785: gcc -o conftest -mno-red-zone -O1 -fno-omit-frame-pointer  -m64 -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -fno-stack-protector -fno-exceptions -isystem /home/yn/Desktop/xen-4.7.1/stubdom/cross-root-x86_64/x86_64-xen-elf/include -isystem /home/yn/Desktop/xen-4.7.1/stubdom/../extras/mini-os/include -D__MINIOS__ -DHAVE_LIBC -isystem /home/yn/Desktop/xen-4.7.1/stubdom/../extras/mini-os/include/posix -isystem /home/yn/Desktop/xen-4.7.1/stubdom/../tools/xenstore/include  -isystem /home/yn/Desktop/xen-4.7.1/stubdom/../extras/mini-os/include/x86 -isystem /home/yn/Desktop/xen-4.7.1/stubdom/../extras/mini-os/include/x86/x86_64 -U __linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem /home/yn/Desktop/xen-4.7.1/stubdom/../extras/mini-os/include/posix -isystem /home/yn/Desktop/xen-4.7.1/stubdom/cross-root-x86_64/x86_64-xen-elf/include -isystem /usr/lib/gcc/x86_64-linux-gnu/5/include -isystem /home/yn/Desktop/xen-4.7.1/stubdom/lwip-x86_64/src/include -isystem /home/yn/Desktop/xen-4.7.1/stubdom/lwip-x86_64/src/include/ipv4 -I/home/yn/Desktop/xen-4.7.1/stubdom/include -I/home/yn/Desktop/xen-4.7.1/stubdom/../xen/include  conftest.c  >&5

Of note is the -isystem /home/yn/Desktop/xen-4.7.1/stubdom/cross-root-x86_64/x86_64-xen-elf/include flag which makes use of the stdio.h from newlib1.16.0, supplanting the default system header. However, it appears that linking still occurs with the default dynamic link library.

The key issue is that ferror(f) consistently returns a non-zero value. After some digging, I determined the discrepancy is rooted in the different definitions of the "struct FILE" between newlib and the system's default.

What perplexes me is that both the compilation flags and the usage of newlib are specified by Xen's configure and makefile. I've experimented with changing the compiler to both gcc-4.8.5 and gcc-8.4.0, but the problem persists.

Any insights or solutions to address this issue would be deeply appreciated.

Thank you in advance for your assistance!

0

There are 0 answers