Problem with building powerpc-rtems4.11-gcc

[Joel Sherrill]

On 09/09/2010 09:16 AM, Steven Grunza wrote:
>> -----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.
>    
I didn't notice this was on a native gcc.  Still probably
worth it to repeat the command by hand with a -v and see
if what as it is using.  Worse case, you might have an old
binutils.
> Upon review of my path; however, I noticed something I consider a
> security error: my path had . in it.
>
>    
It has long been considered a security mistake.  I think this
dates back to the earliest UNIX days. :)
> 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?
>>>
>>>        
>    


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985