Problem with building powerpc-rtems4.11-gcc

Steven Grunza grunza at ulticom.com
Thu Sep 9 14:16:16 UTC 2010


> -----Original Message-----
> From: Joel Sherrill [mailto:joel.sherrill at OARcorp.com]
> Sent: Thursday, September 09, 2010 10:03 AM
> To: Steven Grunza
> Cc: rtems-users at rtems.org
> Subject: Re: Problem with building powerpc-rtems4.11-gcc
> 
> On 09/09/2010 08:55 AM, Steven Grunza wrote:
> > I'm currently changing build machines from a single CPU CentOS4
> box to a
> > Core2Quad CentOS5 box.  Part of the change is the new machine has
> GCC
> > 4.1.2 instead of 3.4.6.  The new machine is also running 64-bit
> (a first
> > for me) instead of 32-bit.
> >
> >
> > Binutils 2.20.1 built and installed ok but gcc 4.5.1 is giving me
> a
> > strange error; it looks like the native compiler can't compile
> the
> > source to gcc-4.5.1:
> >
> What is your PATH when building gcc?  I have a hunch that
> you forgot to put the RTEMS cross-assembler at the head
> of your PATH.  It is likely using the native as which won't
> work for powerpc code. :)


Actually, it should be the native GCC since I'm building the
cross-compiler.  

Upon review of my path; however, I noticed something I consider a
security error: my path had . in it.

grunzasr at c2q% echo $PATH
/opt/rtems4.11/bin:.:/usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/l
ocal/sbin:/usr/X11R6/bin


I removed the . and then the build got past the problem (won't know if
it worked until it finishes building).


I consider the . in my PATH as a security error since it allows a
someone to drop an executable (like vi) in a source directory and when
the victim enters the command "vi foo.c" the victim runs the vi
executable from the current directory instead of from /usr/bin or
wherever it should be.


I'm not sure why having the . in my path caused a problem but I don't
mind removing it so I guess the problem is solved.


> > make[2]: Entering directory
> > `/home/grunzasr/rtems_head/tools/b-gcc-ppc/gcc'
> > gcc -c  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
> > -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-
> prototypes
> > -Wmissing-format-attribute -Wold-style-definition -Wc++-compat
> > -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc-
> 4.5.1/gcc
> > -I../../gcc-4.5.1/gcc/build -I../../gcc-4.5.1/gcc/../include
> > -I../../gcc-4.5.1/gcc/../libcpp/include
> > -I../../gcc-4.5.1/gcc/../libdecnumber
> > -I../../gcc-4.5.1/gcc/../libdecnumber/dpd -I../libdecnumber
> \^M
> >                  -o build/genmodes.o ../../gcc-
> 4.5.1/gcc/genmodes.c^M
> > /tmp/cc4psLZx.s: Assembler messages:^M
> > /tmp/cc4psLZx.s:18: Error: Unrecognized opcode: `movq'^M
> > /tmp/cc4psLZx.s:21: Error: Unrecognized opcode: `movq'^M
> >
> >
> > My various tools are:
> >
> > grunzasr at c2q% gcc --version
> > gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
> >
> >
> > grunzasr at c2q% autoconf --version
> > autoconf (GNU Autoconf) 2.67
> >
> >
> > grunzasr at c2q% automake --version
> > automake (GNU automake) 1.11.1
> >
> >
> > grunzasr at c2q% m4 --version
> > m4 (GNU M4) 1.4.14
> >
> >
> > autoconf-2.67
> > automake-1.11.1
> > binutils-2.20.1
> > gcc-4.5.1
> > gmp-5.0.1
> > m4-1.4.14
> > mpc-0.8.1
> > mpfr-2.4.2
> > newlib-1.18.0
> >
> >
> > I configured the b-gcc-ppc directory with the following:
> >
> > ../gcc-4.5.1/configure --prefix=/opt/rtems4.11
> > --target=powerpc-rtems4.11 --with-gnu-as --with-gnu-ld --with-
> newlib
> > --verbose --enable-threads --enable-languages="c,c++"
> >
> >
> > If this didn't build ok on the CentOS4-32bit machine I would just
> assume
> > user error but I've run out of things to check.  Any suggestions
> on
> > what's wrong or where to look?
> >





More information about the users mailing list