warning removal changes

[Joel Sherrill]

Ralf Corsepius wrote:
> On Mon, 2006-09-04 at 08:43 -0500, Joel Sherrill wrote:
>   
>> Chris Johns wrote:
>>     
>>> Joel Sherrill wrote:
>>>       
>>>> Please update your tree and test.  If you see problems or
>>>> have fixes for other warnings, please help.
>>>>
>>>>         
>>> I have built multilib kernels without bsps for arm i386 m68k mips 
>>> powerpc sh sparc tic4x targets. The get the following error with the 
>>> tic4x:
>>>
>>> gmake[6]: Entering directory 
>>> `/local/tools/rtems/tools/packages/BUILD/rtems-4.7-tic4x-rtems4.7-4.6.99.3/build/tic4x-rtems4.7/cpukit/score/cpu/c4x' 
>>>
>>> if tic4x-rtems4.7-gcc --pipe -DHAVE_CONFIG_H   -I../../.. 
>>> -I../../../../lib/include  -Wall -fasm -g -O2 -MT libscorecpu_a-cpu.o 
>>> -MD -MP -MF ".deps/libscorecpu_a-cpu.Tpo" -c -o libscorecpu_a-cpu.o 
>>> `test -f 'cpu.c' || echo 
>>> '../../../../../../rtems-4.6.99.3/cpukit/score/cpu/c4x/'`cpu.c; \
>>> then mv -f ".deps/libscorecpu_a-cpu.Tpo" ".deps/libscorecpu_a-cpu.Po"; 
>>> else rm -f ".deps/libscorecpu_a-cpu.Tpo"; exit 1; fi
>>> In file included from ../../../../lib/include/rtems/score/cpu.h:28,
>>>                  from ../../../../lib/include/rtems/system.h:184,
>>>                  from 
>>> ../../../../../../rtems-4.6.99.3/cpukit/score/cpu/c4x/cpu.c:15:
>>> ../../../../lib/include/rtems/score/types.h:36: error: syntax error 
>>> before "Priority_Bit_map_control"
>>> ../../../../lib/include/rtems/score/types.h:36: warning: type defaults 
>>> to `int' in declaration of `Priority_Bit_map_control'
>>> ../../../../lib/include/rtems/score/types.h:36: warning: data 
>>> definition has no type or storage class
>>> gmake[6]: *** [libscorecpu_a-cpu.o] Error 1
>>>
>>>       
>> I haven't compiled the tic4x for a while and this looks like something 
>> that has been broken a while.
>> uint16_t is NOT defined for the tic4x. 
>>     
> Right. The tic4x is special (The reason for me to keep the tic4x alive,
> despite we all know the target to be more than dead):
>
> The tic4x does NOT have [u]int16_t nor [u]int8_t, also the common
> (bogus) assumptions on sizeof(char) == 8bit and sizeof(short) == 16bit
> does not apply (on the tic4x all sizeof(any type) = 1 == 32bit).
>
> The least-size types ([u]int_least<size>_t) however are available on the
> tic4x, but beware: There is no guarantee of them being "minimal" nor of
> them being optimal.
>
>   
Nothing is optimal on the tic4x. Imagine how much space a string can waste.

I recall that the TI C compiler and Tartan Ada compiler had special string
code to pack strings into every byte inside a word.

> => To make types portable to the tic4x you could use the least-size
> types instead of fixed size types (That's what my RTEMS "hash"-patch to
> newlib does (part of the current rtems newlib-patch)) or you could
> conditionally define them.
>   

So if the tic4x newlib patch were updated it would magically get these 
types?
> Better, do not use any fixed size types, but ... due to current RTEMS
> basic types design, this is hardly possible.
>   

Yes and to get rid of warnings I have added even more use of fixed sized 
types.

>   
>> Also I didn't have the tic4x tools installed and got this error.  
>> Something is wrong with the
>> RPM DB on england:
>>
>> rpmdb: Program version 4.3 doesn't match environment version
>> error: db4 error(-30974) from dbenv->open: DB_VERSION_MISMATCH: Database 
>> environment version mismatch
>> error: cannot open Packages index using db3 -  (-30974)
>> warning: cannot open Solve database in 
>> /usr/lib/rpmdb/i386-redhat-linux/redhat
>> rpmdb: Program version 4.3 doesn't match environment version
>> error: db4 error(-30974) from dbenv->open: DB_VERSION_MISMATCH: Database 
>> environment version mismatch
>>
>> Any ideas?
>>     
> The FC1 ... not unlikely bugs in its rpm implementation.
>   
Strange problem.  Apparently since this computer was initially FC3 and 
updated, there
was a package in the DB causing this problem.  When I removed it, the 
problem went
away.  From Google, it looks like this is a recurring problem on 
machines which
get upgraded and some significant change occurred between the original 
OS version
and the final updated one.

> Ralf
>
>