Luca Saiu
2016-10-13 02:11:47 UTC
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,
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".
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".