Autoconf and a bare-metal host with no C library

[Luca Saiu]

Hello.

After playing with kernel-mode programming for a while tonight I finally
decided to add autotools support to my little kernel, and I stumbled on
a problem.  I'm not writing to bug-autoconf as I can't really believe
this is the first time you hear about this, but if web searches weren't
useful maybe we need to at least document this.

I'm generating code for i386-whatever-elf, without a C library; for my
use case having no libraries is okay: I use C with a little assembly to
generate a static ELF binary not linked to anything except libgcc, to be
booted from Grub.  The very few primitives I need, I write myself.

I used crosstool-ng to build a i386-unknown-elf-gcc cross-compiler and
the appropriate cross-binutils, which work fine.  From the crosstool-ng
configuration I intentionally chose to have no C library, thinking it
was the correct option for my case; and indeed everything works when
compiling from a script or a hand-written makefile.

So the problem is simple: as soon as I add

--8<---------------cut here---------------start------------->8---
AC_PROG_CC
--8<---------------cut here---------------end--------------->8---

to configure.ac, the generated configure fails with

--8<---------------cut here---------------start------------->8---
configure: error: C compiler cannot create executables
See `config.log' for more details
--8<---------------cut here---------------end--------------->8---

, which is not very surprising.  The C compiler indeed cannot generate
standalone programs, without crt0.o .

AC_CANONICAL_BUILD , AC_CANONICAL_HOST (and AC_CANONICAL_TARGET) do
their job fine; I can do all my tests on $host_architecture and $host_os
in configure.ac , but as soon as I test any compiler feature AC_PROG_CC
is AC_REQUIRE'd by another macro, which causes a fatal error in configure.

Maybe I could even live without compiler feature checks in configure,
but things turn very ugly when Automake complains about CC and CCAS not
being defined.  Even if I try to brutally AC_DEFINE them in configure.ac
Automake still complains about missing definitions for am__fastdepCCAS
and AMDEP not appearing in AM_CONDITIONAL , which I don't understand and
the user is probably not supposed to see.


Now, of course I can work around my problem in practice.  I could spend
ten minutes building a different cross-compiler, or even use a native
compiler in the common case: compiling from x86_64 GNU/Linux with -m32
works.  But supporting cross-compilers here is clearly the right thing,
and there must be some other case where an embedded platform is too
small or too new to support a runtime library.

The logic in AC_PROG_CC is nice, and useful; I would like to use it
(along with AM_PROG_AS, which now requires AC_PROG_CC) without configure
bailing out "just" because the compiler cannot make executables.  I
understand that checking compiler features without being able to link
executables is more difficult for Autoconf.  I guess that in theory you
could use kludges like

--8<---------------cut here---------------start------------->8---
#if sizeof (int) == 4
  /* nothing */
#else
  #error "not 4"
#endif
--8<---------------cut here---------------end--------------->8---

and compile without linking in feature tests, but that would be quite
painful on your side.

So, what I'm asking you is: does a clean solution exist, or compiling
without a runtime library is just not supported by the Autotools?  It
sounds weird to say that for configuring you need a cross-compiler with
support for a runtime that will never even be linked when building.
Shouldn't there be, at least, one variant of AC_PROG_CC which doesn't
fail in a fatal way?

I'm not yet linking the code in a public forum just because it still
lacks copyright and license headers; but in case it were useful to you,
even if I doubt it, I can clean it up and publish it.

Let me thank you in advance for any suggestion, and in any case for your
work, which is awesome.

Regards,

-- 
Luca Saiu
* GNU epsilon:           http://www.gnu.org/software/epsilon
* My personal home page: http://ageinghacker.net

I support everyone's freedom of mocking any opinion or belief, no
matter how deeply held, with open disrespect and the same unrelented
enthusiasm of a toddler who has just learned the word "poo".

signature.asc
Description: PGP signature