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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.10.16 at 14:50, <wei.liu2@xxxxxxxxxx> wrote:
> 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.

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

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

Jan

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