Re: Stubdom GMP build failure for gcc 6

Re: Stubdom GMP build failure for gcc 6

[Pry Mar]

[-- Attachment #1.1: Type: text/plain, Size: 460 bytes --]

Wei,

[PATCH] glibc 223 fix gmp-crosslib config error
http://paste.fedoraproject.org/462654/14777176/

I've used this patch since last spring. This is a configure bug which stops
the Stubdom build. The bug first appeared in Ubuntu 16.04 when they went to
libc6 2.23+. Next, Stretch followed with the same upgrade. It has nothing
to do with gcc version.

In the above patch, I posted a link to the developer on the aur-xen list
that saw the solution.

PryMar56

[-- Attachment #1.2: Type: text/html, Size: 610 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

Re: Stubdom GMP build failure for gcc 6

[Wei Liu]

On Fri, Oct 28, 2016 at 10:16:12PM -0700, Pry Mar wrote:
> Wei,
> 
> [PATCH] glibc 223 fix gmp-crosslib config error
> http://paste.fedoraproject.org/462654/14777176/
> 
> I've used this patch since last spring. This is a configure bug which stops
> the Stubdom build. The bug first appeared in Ubuntu 16.04 when they went to
> libc6 2.23+. Next, Stretch followed with the same upgrade. It has nothing
> to do with gcc version.
> 

Right. Thanks for the information regarding glibc version.

I wouldn't call that a glibc bug thought. It's actually a bug in stubdom
build system.

I've posted a patch to fix this issue properly.

http://marc.info/?l=xen-devel&m=147776183718177&w=2

Wei.

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

Re: Stubdom GMP build failure for gcc 6

[Wei Liu]

On Fri, Oct 28, 2016 at 01:50:36PM +0100, Wei Liu 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.
> 
> 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.

This is the key to fix this issue -- I didn't even notice it when I
wrote this down!

After going through its configure script options, I found a way to make
it aware of cross-compilation.

Wei.

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

Re: Stubdom GMP build failure for gcc 6

[Ian Jackson]

Wei Liu writes ("Re: Stubdom GMP build failure for gcc 6"):
> On Fri, Oct 28, 2016 at 02:30:02PM +0100, Ian Jackson wrote:
> > Can we not just reproduce its link line somehow ?
> 
> I don't think that would result in a program that can run on Linux.

Well, yes, sorry, I took it as read that we would say we were
cross-compiling.

Ian.

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

Re: Stubdom GMP build failure for gcc 6

[Wei Liu]

On Fri, Oct 28, 2016 at 04:44:10PM +0200, Juergen Gross wrote:
> On 28/10/16 14:10, Wei Liu wrote:
> > Hi all
> > 
> > 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.
> > 
> > So what should we do with this? I'm not sure if I can come up with a
> > non-intrusive patch quickly.  GMP is only used by tpm emulator, so for
> > the imminent 4.8 release I can write a patch to disable building that.
> > 
> > Ultimately we need to have a proper solution, because there can be other
> > breakages in the future. And I do wish users who need tpm emulator can
> > continue to use it. I don't have a clear answer as to how many people
> > care about this and how can we fix it.
> > 
> > Thoughts?
> 
> I just tried to verify it is working (or failing) for me. On the machine
> I normally did my Xen builds cmake was missing so it never tried to
> build libgmp. After installing it I saw the following problem:
> 
> at the end of libgmp build:
> Libraries have been installed in:
>    /home/gross/xen/stubdom/cross-root-x86_64/x86_64-xen-elf/lib64
> 
> and when trying to link stubdom-vtpm:
> make[2]: Entering directory '/home/gross/xen/extras/mini-os-remote'
> ld -r -d -nostdlib
> -L/home/gross/xen/stubdom/cross-root-x86_64/x86_64-xen-elf/lib  -m
> elf_x86_64 -\( /home/gross/xen/stubdom/vtpm/vtpm.a -T app.lds -\) -ltpm
> -ltpm_crypto -lgmp -lpolarssl --undefined main -o
> /home/gross/xen/stubdom/mini-os-x86_64-vtpm/mini-os_app.o
> ld: cannot find -lgmp
> 
> manually adding
> "-L/home/gross/xen/stubdom/cross-root-x86_64/x86_64-xen-elf/lib64" lets
> the link command succeed.
> 

This is a different issue from the one I report here.

But both stems from the fact that we don't really create a complete
cross-compile toolchain for stubdom, but piggy-back on the host
toolchain.

Presumably you didn't see my issue because you're using an older version
of glibc.

Wei.

> 
> Juergen

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

Re: Stubdom GMP build failure for gcc 6

[Juergen Gross]

On 28/10/16 14:10, Wei Liu wrote:
> Hi all
> 
> 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.
> 
> So what should we do with this? I'm not sure if I can come up with a
> non-intrusive patch quickly.  GMP is only used by tpm emulator, so for
> the imminent 4.8 release I can write a patch to disable building that.
> 
> Ultimately we need to have a proper solution, because there can be other
> breakages in the future. And I do wish users who need tpm emulator can
> continue to use it. I don't have a clear answer as to how many people
> care about this and how can we fix it.
> 
> Thoughts?

I just tried to verify it is working (or failing) for me. On the machine
I normally did my Xen builds cmake was missing so it never tried to
build libgmp. After installing it I saw the following problem:

at the end of libgmp build:
Libraries have been installed in:
   /home/gross/xen/stubdom/cross-root-x86_64/x86_64-xen-elf/lib64

and when trying to link stubdom-vtpm:
make[2]: Entering directory '/home/gross/xen/extras/mini-os-remote'
ld -r -d -nostdlib
-L/home/gross/xen/stubdom/cross-root-x86_64/x86_64-xen-elf/lib  -m
elf_x86_64 -\( /home/gross/xen/stubdom/vtpm/vtpm.a -T app.lds -\) -ltpm
-ltpm_crypto -lgmp -lpolarssl --undefined main -o
/home/gross/xen/stubdom/mini-os-x86_64-vtpm/mini-os_app.o
ld: cannot find -lgmp

manually adding
"-L/home/gross/xen/stubdom/cross-root-x86_64/x86_64-xen-elf/lib64" lets
the link command succeed.


Juergen

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

Re: Stubdom GMP build failure for gcc 6

[Wei Liu]

On Fri, Oct 28, 2016 at 02:30:02PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Stubdom GMP build failure for gcc 6"):
> > 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.
> 
> How does stubdom link its actual final program, without a crt0 ?
> 

It chdir to mini-os and uses linker script provided there.

> Can we not just reproduce its link line somehow ?
> 

I don't think that would result in a program that can run on Linux.

Wei.

> Ian.

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

Re: Stubdom GMP build failure for gcc 6

[Ian Jackson]

Wei Liu writes ("Stubdom GMP build failure for gcc 6"):
> 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.

How does stubdom link its actual final program, without a crt0 ?

Can we not just reproduce its link line somehow ?

Ian.

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

Re: Stubdom GMP build failure for gcc 6

[Wei Liu]

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

Re: Stubdom GMP build failure for gcc 6

[Jan Beulich]

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

>> 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@lists.xen.org
https://lists.xen.org/xen-devel

Re: Stubdom GMP build failure for gcc 6

[Wei Liu]

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.

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@lists.xen.org
https://lists.xen.org/xen-devel

Re: Stubdom GMP build failure for gcc 6

[Jan Beulich]

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

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.

Jan

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

Stubdom GMP build failure for gcc 6

[Wei Liu]

Hi all

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.

So what should we do with this? I'm not sure if I can come up with a
non-intrusive patch quickly.  GMP is only used by tpm emulator, so for
the imminent 4.8 release I can write a patch to disable building that.

Ultimately we need to have a proper solution, because there can be other
breakages in the future. And I do wish users who need tpm emulator can
continue to use it. I don't have a clear answer as to how many people
care about this and how can we fix it.

Thoughts?

Wei.

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