If CC is specified, fdlibm fails to cross compile

[mikrosk]

CC=gcc ./configure --host=m68k-atari-mint leads to:

checking build system type... x86_64-unknown-linux-gnu
checking host system type... m68k-atari-mint
checking for m68k-atari-mint-gcc... gcc

[th-otto]

That's just wrong usage, and will fail with any configure based package.

[mikrosk]

That's not true. Random configure-based project:

[mikro@w510 openttd.git]$ CC=gcc ./configure --host=m68k-atari-mint
checking awk... awk
detecting OS... UNIX
checking build system type... x86_64-pc-linux-gnu
checking host system type... m68k-atari-mint-gcc not found
I couldn't detect any gcc binary for m68k-atari-mint

If it were as you say, it wouldn't complain about missing m68k-atari-mint-gcc (which I don't have on this computer). So it is a bug in fdlibm.

[th-otto]

Maybe other scripts behave slightly different, it sometimes depend which autoconf version was used to create the script, and whether it is using AC_CANONICAL_TARGET and/or AC_CANONICAL_HOST

But setting the CC variable in the invocation to the hosts compiler, when you actually want to cross-compile, is not going to work. I wonder what sense that should make?

[mikrosk]

It would make that sense that Travis sets CC by itself when choosing between clang or gcc. So in my binutils/gcc build I may want to compile it by both using Travis matrix but still have m68k-atari-mint-gcc used for atari libraries (mintlib, fdlibm). Now I have to explictly unset CC before fdlibm compilation.

This is the first time I see something like this, maybe fdlibm's configure has been generated differently, yes.

[th-otto]

But we don't have the choice to use clang when cross-compiling????

[mikrosk]

Who is "we" ? I can cross compile m68k-atari-mint-gcc with clang without any problem. It's default for MacOS X build in fact.

[th-otto]

How i'm really confused. Since when is clang able to cross-compile to the mint target?

Looks like you are mixing up different things.

[mikrosk]

No Thorsten, you're just jumping into conclusions too fast. m68k-atari-mint-gcc is a Linux binary. Linux binaries can be compiled with different compilers. gcc is one of them, clang is another. There's nothing wrong with having Travis building m68k-atari-mint-gcc with both compilers.

[th-otto]

Sure, the initial cross-compiler must be compiled with some native compiler, and that can also be clang.
But you opened the issue about compiling fdlibm, not m68k-atari-mint-gcc. fdlibm (at least for our purpose) can only be compiled by m68k-atari-mint-gcc

[mikrosk]

Sure. But m68k-atari-mint-gcc (the linux binary) build process contains also building fdlibm (natively, this time). So preliminary m68k-atari-mint-gcc (compiled by clang) -> mintlib/fdlibm (where CC interferes, compiled by the preliminary gcc) -> final m68k-atari-mint-gcc (again by clang). Now I have to juggle with CC only because of that fdlibm step.

[th-otto]

So preliminary m68k-atari-mint-gcc (compiled by clang) -> mintlib/fdlibm (where CC interferes, >compiled by the preliminary gcc) -> final m68k-atari-mint-gcc

That's exactly the dependencies we want to avoid. Just install a previously compiled fdlibm before compiling gcc, then you also don't need that extra steps. Such circular dependencies are only needed when bootstrapping a compiler on a platform that was not supported before, but that is not the case.

BTW, i'm not even sure whether some math library is needed to build a cross-compiler. gcc should use mpfr/gmp to deal with any float formats. It might be needed though when building the c++ compiler and libstdc++, at least the configure script of libstdc++ somehow depends on the math.h header file being available.

[mikrosk]

Such circular dependencies are only needed when bootstrapping a compiler on a platform that was not supported before, but that is not the case.

... unless someone wants to test the bootstrapping process. Which is exactly what I'm doing.

The point is, fdlibm behaves differently here, it doesn't matter for what reasons. So that's why I'm reporting it, if for nothing else then as a clue for other who see similar errors.

[th-otto]

Not really. If you run your example in the awk directory, on a system where m68k-atari-mint-gcc is installed:

$ CC=gcc ./configure --host=m68k-atari-mint
checking build system type... x86_64-pc-linux-gnu
checking host system type... m68k-atari-mint
checking for style of include used by make... GNU
checking for m68k-atari-mint-gcc... m68k-atari-mint-gcc
...
$ make
gcc -DDEFPATH='".:/usr/local/share/awk"' -DDEFLIBPATH="\"/usr/local/lib/gawk\"" -DSHLIBEXT="\"so"\" -DHAVE_CONFIG_H -DGAWK -DLOCALEDIR='"/usr/local/share/locale"' -I.     -g -O2 -DNDEBUG -MT array.o -MD -MP -MF .deps/array.Tpo -c -o array.o array.c

So it will use the native compiler, because you had overridden it on the command line. This is surely not what you want when cross-compiling. Conclusion: if you have configure-based projects, and want to cross-compile using --host=... then you just must not explicitly set $CC

The problem just shows up because you are doing two very different things in the same script. Compiling a cross-compiler will create a native executable for your host (and using a different compiler for it like clang is perfectly valid). Compiling something else, using that freshly created cross-compiler, will create an executable/library for your target, which is a different thing, and using anything else than your targets cross-compiler will just not work.