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".
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
