Re: Stubdom GMP build failure for gcc 6

[Wei Liu <wei.liu2@citrix.com>]

On Fri, Oct 28, 2016 at 06:56:39AM -0600, Jan Beulich wrote:
> >>> On 28.10.16 at 14:50, <wei.liu2@citrix.com> wrote:
> > On Fri, Oct 28, 2016 at 06:29:49AM -0600, Jan Beulich wrote:
> >> >>> On 28.10.16 at 14:10, <wei.liu2@citrix.com> 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.
> 
> I agree, and tried to indicate so with the last sentence. It was just
> a thought for a possible non-intrusive workaround for 4.8.
> 
> > 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.
> 
> Considering what you write further down, DYM "does try to run"
> (in which case indeed we're hosed)?
> 

Yes, I meant "does try to run".

> >> 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.
> 
> But how is any of this gcc version dependent?
> 

Oh, yes, the subject line is misleading. Sorry.

I wrote that because it was discovered in the context of trying to
compile stubdom gmp with gcc 6.

Wei.

> Jan
> 

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