C compiler cannot create executables

[Amalaye Oyake]

Hello Ralf, to clarify:

* Bleeding Edge was referring to the latest "Ubuntu Edgy", not the toolset,
I know that is stable. I was implying that I was trying to compile the
toolset on a 64bit host box and with a new distro release ... I feel I
should have been using something more reasonable as a host.

* My comment on Ubuntu's autotools: autoconf was the latest, but automake
was old ... this may be a packaging bug on their part, but this is what I
got when I downloaded the ISO and installed it ... automake --version said
1.4. I couldn't believe it ... but it is true. So I removed it and installed
the latest one from source.

* Since Ubuntu is a Debianish disto, I was likely encountering the problem
you mentioned.

Your comments are helpful in understanding some is going on.

Regards,
Amalaye 

-----Original Message-----
From: Ralf Corsepius [mailto:ralf.corsepius at rtems.org] 
Sent: Monday, April 02, 2007 10:36 AM
To: Amalaye.Oyake-104920 at jpl.nasa.gov
Cc: Joel Sherrill; Amalaye Oyake; rtems-users at rtems.org
Subject: Re: C compiler cannot create executables

On Mon, 2007-04-02 at 09:42 -0700, Amalaye Oyake wrote:
> Hello Joel (and thanks Ralf for some of the tips),
> 
> I will be very detailed so this can be referenced by others ... I
> was trying to build RTEMS on a 64bit machine running Ubuntu Edgy
> ... there were various issues, but I worked around them. I did
> two things (there were two issues) ... had to install Ubuntu
> 32bit and installed an updated automake.
Hmm, this doesn't seem right to me.

You shouldn't have to install a 32bit Ubuntu nor a 32bit native GCC.

Wrt. to autoconf and automake, RTEMS-4.7.x requires
autoconf >= 2.60 and automake >= 1.10

> Thus I did away with my 64bit Ubuntu (no negative impact to me)
> and went 'backwards' with 32bit Ubuntu. The problem seems to be
> more of a gcc issue.
Well, there are at least two issues I am aware about.

1. there is a bug in rtems-4.7.1 which causes some parts of the sources
tree to receive bogus CFLAGS.

Affected are the powerpc mvme162 BSPs and the pc386-based BSPs on all
host plattforms. The pc386-BSPs only do not show on ix86-platforms,
because the bogus CFLAGS being used also (by random accident) also are
valid on i386 plattforms.

2. Some Debian based native GCCs are reported (Repeatedly reported for
amd64-Debian) to contain a bug related to multilib's (i.e. -m32/-64). 

>  64bit Ubuntu Edgy does not ship with a
> 'multilib' gcc. Thus if you are compiling things like Wine and
> RTEMS on a 64bit machine you could have this problem ... perhaps
> someone more knowledgeable on multilib and compiler stuff can
> expand on this.
RTEMS (except of the posix bsp) is independent of a host's multilibs.

> Furthermore when checking out of cvs the bootstrap script
> requires automake/autoconf = latest_version. Ubuntu as a whole
> ships with a very very old automake (something like version 1.4)

Really?!? I hardly can believe this - 1.4 is dead and unmaintained for 5
or 6 years. This alone would be sufficient reason not to be wanting to
use these distros.

However, you can easily work around this issue by installing autoconf
and automake to an alternative prefix from the tarballs (We are using
vanilla FSF sources=

> Otherwise, with the necessary adjustments 4.7.0 compiled just fine! 
> 
> If you 'have' to be in a 64bit world chroot may be a work-around
> ... but sometimes being on the bleeding edge just makes you bleed
> unnecessarily... 

Bleeding edge? Sorry, the tools aren't bleeding edge. They are the
official stable versions.

Ralf