Re: Autoconf and a bare-metal host with no C library

[Luca Saiu]

Hello.

On 2016-10-13 at 15:48, Keith Marshall wrote:

> Or maybe, you could consider something along the lines of
> MINGW_AC_PROG_CC_COMPILE_ONLY, (and associated support macros), as
> included within this aclocal.m4:
> https://sourceforge.net/p/mingw/mingw-org-wsl/ci/5.0-active/tree/aclocal.m4

Very interesting, thanks.

Thanks to Russell, Zack and Robert as well.  I would like to get to a
clean solution to contribute, but realistically my understanding of the
Autoconf internals is still far too shallow.

If I ever get to something reusable I'll contact you.

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
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Autoconf and a bare-metal host with no C library

[Robert Woodworth]

I don't have an example, but I have done this in the past.

Autoconf need to know that the host and target are different, then it will
not try the 'native' CC to check for local executable.

On Thu, Oct 13, 2016 at 8:48 AM, Keith Marshall <
keith.d.marsh...@ntlworld.com> wrote:

> On 13/10/16 15:24, Russell Shaw wrote:
> > On 13/10/16 13:11, Luca Saiu wrote:
> >
> > ...
> > > 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.
> >
> > It can be messy and take quite some time to figure out what to do, but
> this kind
> > of stuff is handled in the autoconf/automake/autogen build system of
> binutils
> > and gcc. Not a quick and easy path for the uninitiated though.
>
> Or maybe, you could consider something along the lines of
> MINGW_AC_PROG_CC_COMPILE_ONLY, (and associated support macros), as
> included within this aclocal.m4:
> https://sourceforge.net/p/mingw/mingw-org-wsl/ci/5.0-
> active/tree/aclocal.m4
>
> --
> Regards,
> Keith.
>
>
> ___
> Autoconf mailing list
> Autoconf@gnu.org
> https://lists.gnu.org/mailman/listinfo/autoconf
>
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Autoconf and a bare-metal host with no C library

[Keith Marshall]

On 13/10/16 15:24, Russell Shaw wrote:
> On 13/10/16 13:11, Luca Saiu wrote:
> 
> ...
> > 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.
> 
> It can be messy and take quite some time to figure out what to do, but this 
> kind 
> of stuff is handled in the autoconf/automake/autogen build system of binutils 
> and gcc. Not a quick and easy path for the uninitiated though.

Or maybe, you could consider something along the lines of
MINGW_AC_PROG_CC_COMPILE_ONLY, (and associated support macros), as
included within this aclocal.m4:
https://sourceforge.net/p/mingw/mingw-org-wsl/ci/5.0-active/tree/aclocal.m4

-- 
Regards,
Keith.


___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Autoconf and a bare-metal host with no C library

[Zack Weinberg]

On Thu, Oct 13, 2016 at 10:24 AM, Russell Shaw  wrote:
> On 13/10/16 13:11, Luca Saiu wrote:
> ...
>> 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.
>
> It can be messy and take quite some time to figure out what to do, but this
> kind of stuff is handled in the autoconf/automake/autogen build system of
> binutils and gcc. Not a quick and easy path for the uninitiated though.

As I recall, what gcc/binutils do about a very similar problem is
considered an awkward kludge, and if you could contribute to a
_proper_ solution, your help would be most welcome.  You might want to
bring up the problem you're having on the g...@gcc.gnu.org mailing
list, as that will be seen by more people who understand how this
kludge works.  I can tell you that grepping libstdc++-v3 for the
string "NO_EXECUTABLES" is likely to provide some hints, but it has
been more than ten years since I had to touch it myself.

zw

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Autoconf and a bare-metal host with no C library

[Russell Shaw]

On 13/10/16 13:11, Luca Saiu wrote:

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

It can be messy and take quite some time to figure out what to do, but this kind 
of stuff is handled in the autoconf/automake/autogen build system of binutils 
and gcc. Not a quick and easy path for the uninitiated though.



___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Symbian support

[fedor_qd]

I want add support for Symbian OS. I want get static and dynamic libraries via 
configure& make. Digging in sources sometimes very hard. I will be glad to 
share all my Symbian knowledge if someone can help merge it with gnu autoconf.
Always yours, Fiodar Stryzniou


___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

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
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf