Re: [Xen-devel] Stubdom GMP build failure for gcc 6

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Fri, Oct 28, 2016 at 06:29:49AM -0600, Jan Beulich wrote:
> >>> On 28.10.16 at 14:10, <wei.liu2@xxxxxxxxxx> wrote:
> > There have been a few reports on stubdom build failure with gcc 6
> > toolchain. I spent some time yesterday to figure what went wrong. Here
> > is what I found.
> > 
> > When building GMP library, its configure script generates small C
> > programs to determine various aspects of the system. Unfortunately the
> > build rune for it is incorrect, so the test program ends up consuming
> > newlib headers while linking against the host glibc. It's amazing that
> > this even worked in the past few years! :-)
> > 
> > Unfortunately my attempt to fix it by providing LDFLAGS="-nostdlib
> > -LXXX" doesn't work. It turns out that there is no crt generated in
> > newlib. I'm not sure if that's because the newlib port is incomplete or
> > I haven't discovered a way to teach it to generate one.
> 
> Considering that they can't reasonably try to run any of these
> test programs (after all this is a cross build), wouldn't it suffice to
> make up crt*.o just for the configure process, and just providing
> the necessary symbols to make linking succeed? Agreed this, if
> anything, makes the present situation even uglier, but it might
> work.
> 

It might. But that's not sustainable IMO.

One thing is that gmp configure doesn't try to run those test programs,
because the configure rune doesn't indicate a cross-build, although it
is actually one.

> But what I'm not understanding - what did change with gcc 6
> here? There's surely no libc version dependency in the compiler,
> so whatever worked in older gcc for linking purposes should work
> here too.
> 

It's not it doesn't link anymore.

A sample test 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;
}

ferror is a macro in newlib, which checks if one certain bit X is set. I
suppose the same bit X has a different semantics now in glibc, and then
fprintf (a function from glibc) happens to set bit X. This program will
then exit with non-zero and configure deems it failed to run.

Wei.
 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel