On Fri, Jul 06, 2018 at 09:46:36AM -0400, Michael Meissner wrote:
> On Fri, Jul 06, 2018 at 10:16:34AM -0300, Tulio Magno Quites Machado Filho
> wrote:
> > I suggest to test with the following program:
> >
> > #include <math.h>
> >
> > int
> > main ()
> > {
> > return !isinfl(__builtin_infl());
> > }
> >
> > Build it with:
> > gcc -mabi=ieeelongdouble -fno-builtin -Wno-psabi -lm test-ldbl.c
> >
> > If the execution of the program returns 0, your math library supports IEEE
> > long
> > double.
>
> Thanks, but I suspect that it won't work for building cross compilers or for
> building where the compiler built uses the Advance Toolchain libraries and
> shared library loader instead of the system versions using the configuration
> option --with-advance-toolchain=atx.y.
>
> The issue is you need to test whether the target GLIBC has the support when
> configuring the compiler, but if you are building for a cross target, you
> can't
> run the resulting binary. Even on a native system, with options like
> --with-advance-toolchain and --with-sysroot, the libraries used by the host
> compiler used to build stage1 of GCC might be different from the libraries
> used
> to build the target compiler (or stage2/stage3 in a bootstrap native build).
>
> So I used the GLIBC version tests that were already part of the GCC
> configuration.
>
> If there is a simple method that works for cross compilers or where a
> specified
> sysroot is used, it would be simpler than having version checks.
Version checks are terrible. This is nothing new.
For cross builds you can just assume it works. That should work fine here.
For cross builds the burden of having compatible versions of everything is
on the user anyhow (I'm not saying this is a good thing, but this is the
status quo).
Maybe some test could be done that mimics what happens 10m into a build
(the build failure)? But Tulio's test should be okay for most cases, too.
Segher
