public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Kai Ruottu <karuottu@mbnet.fi>
To: Tom Bachmann <e_mc_h2@web.de>
Cc: gcc-help@gcc.gnu.org
Subject: Re: Building OS independant cross compilers (for ia64)
Date: Mon, 17 Jul 2006 18:44:00 -0000	[thread overview]
Message-ID: <44BBDD81.8020505@mbnet.fi> (raw)
In-Reply-To: <44B80C44.5000909@web.de>

Tom Bachmann kirjoitti:
> I try to write a little toy kernel for ppc64 and ia64, mainly to get to
> know the architectures. Actually this message is about 2 question, one
> the one hand, they're tightly related, on the other hand they're
> relatively different (therefore I wasn't sure whether to send 2 messages
> or not).
>
> The first question is about what target to build in my case.
> Conceptually I want a completely OS-independant toolchain only
> consisting of binutils and a C compiler, but which target expresses
> this? <target>-unknown-unknown doesn't work (system not recognized).
 I would think that there isn't that much difference between
targets for the same CPU if needing only the GCC binaries...
But producing the GCC-helper library, 'libgcc', then is quite
target dependent.  Linuces, SVR4s etc. having the soft-float
routines in their kernels but embedded targets having these
produced into the 'libgcc'.  Then threads etc. are target
dependent...
>  For
> ppc64, the following configuration options seem to do what I want:
> "--prefix=... --target=powerpc64-unknown-linux-gnu --enable-languages=c
> - --disable-shared --disable-threads --without-headers --disable-libssp
> - --disable-libmudflap".
>
> But the ia64 cross toolchains thing seems to be even more tricky. For
> what I know it depends on glibc (depending on kernel-headers?), but I
> definitely don't want glibc. I don't think it is conceptually right to
> depend on linux kernel headers or glibc headers if neither is used. So
> what should one pass here?
 Requiring to produce 'libgcc' with the new GCC is one thing...
Maybe it really isn't obligatory at all?   Maybe "producing the
'libgcc.a' etc. stuff" via commands like:

    touch libgcc.a

is enough...   Sometimes people are blind and cannot see that
they could create what the GCC build process cannot create.
But the "created" stuff being really unimportant and using any
time to solve how on earth that unimportant stuff could be
created automatically in the process being only wasted time...

>  I tried some options
> (--target=ia64-unknown-elf, --with-newlib) to workaround this, without
> success (always problems compiling fde-glibc.c obviously related to
> headers [stdlib.h, link.h] not found).
>   
 Are you sure you really need that 'libgcc' for ia64?   Or this
'fde-glibc.o' routine?  Using a 'touch fde-glibc.o' in the
$build/gcc/libgcc' will "produce" it quite surely, it only is an
empty file and unusable but who cares if it is not needed ever?

 Things you are struggling with are quite common and usually
people claim it being impossible to create "only a bare stripped
GCC"  without any libraries... And the main reason being that
the things teached  in the  "Basic course in Unix" were forgotten
long time ago, like "How to create files in Unix" :-)
 

      parent reply	other threads:[~2006-07-17 18:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-14 21:29 Tom Bachmann
2006-07-15 10:36 ` Tom Bachmann
2006-07-17 18:44 ` Kai Ruottu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44BBDD81.8020505@mbnet.fi \
    --to=karuottu@mbnet.fi \
    --cc=e_mc_h2@web.de \
    --cc=gcc-help@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).