[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Autoconf and a bare-metal host with no C library

From: Luca Saiu
Subject: Autoconf and a bare-metal host with no C library
Date: Thu, 13 Oct 2016 04:11:47 +0200
User-agent: Gnus (Gnus v5.13), GNU Emacs, x86_64-unknown-linux-gnu


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---
--8<---------------cut here---------------end--------------->8---

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

their job fine; I can do all my tests on $host_architecture and $host_os
in , 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
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 */
  #error "not 4"
--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.


Luca Saiu
* GNU epsilon: 
* My personal home page:

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

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]