public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mark Butcher <M_J_BUTCHER@compuserve.com>
To: gcc-help <gcc-help@gcc.gnu.org>
Cc: gcc <gcc@gcc.gnu.org>
Subject: Tutorial Time - part 2
Date: Thu, 13 Jun 2002 11:09:00 -0000	[thread overview]
Message-ID: <200206131409_MC3-1-211-CF66@compuserve.com> (raw)

Hi All

As a comparison, I have spent some time today attempting a cross build of
an ARM-ELF target.

It was interesting in as much as it got passed the stage which the Mcore
had problems with and says that it is using the sjlj exception model
(short-jump-long-jump as I discovered in
GCC-3.0.4/LIBSTDC++-V3/DOCS/HTLM/configopts.html).

This time the error is due to:
configure: error: installation or configuration problem: C compiler can not
create executable.

I checked out some details and found that the problem is this time in
libiberty, where the compiler is tested by compiling a test program called
conftest.c with the content:


#line 1945 "configure"
#include "confdefs.h"

main(){return(0);}


The command used is:

/usr/local/src/gnu/BUILD/gcc/gcc/xgcc -B/usr/local/src/gnu/BUILD/gcc/gcc/
-B/usr/local/arm/arm-elf/bin/ -B/usr/local/arm/arm-elf/lib/ -isystem
/usr/local/arm/arm-elf/include -g -O2 conftest.c



I have run this command and receive the same compiler error (actually a
linker error)

/usr/local/arm/arm-elf/bin/ld: cannot open crt0.o: No such file or
directory
collect2: ld returned 1 exit status


At this point I am not sure what has gone wrong since crt0 does not seem to
be a part of ARM (I have seen that crtend.o and crtbegin.o, I assume the
ARM equivalents, have been created in the build directory  gcc and also
gcc/thumb). It seems as though these programs are needed to create an
executable - hopefully for the target and not the host...



Now I assume that many more gcc-users have experience with ARM than with
Mcore, so there may be someone out there who knows why this can go wrong -
possibly a configuration error ? Since it takes about 5 hours on my slow PC
at home to retry with different configuration parameters I will wait to see
whether someone sends a recommendation first (in the lists of successful
test reports I have found several examples - for example one using
--disable-nls and another using --with-newlib plus --enable-obselete%g
[haven't found a description of this one] - neither of which seems to be
critical).

Cheers

Mark in Switzerland


             reply	other threads:[~2002-06-13 18:09 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-13 11:09 Mark Butcher [this message]
2002-06-14  0:54 ` Alexandre Oliva
2002-06-16 15:42 Mark Butcher

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=200206131409_MC3-1-211-CF66@compuserve.com \
    --to=m_j_butcher@compuserve.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=gcc@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).