New tools and 4.6.99.3

[Joel Sherrill]

Steven Johnson wrote:

>Ralf Corsepius wrote:
>
>  
>
>>On Thu, 2006-04-27 at 13:32 +1100, Steven Johnson wrote:
>> 
>>
>>    
>>
>>>Hi,
>>>
>>>Ive just started moving my project over to 4.6.99.3, and here is what I
>>>have to report:
>>>
>>>I'm building the Bare BSP for a custom MPC862 target.
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>pppd and zlib:
>>>
>>>I have discovered that ZLib has crept its way inside the rtems source
>>>tree.  A first glance seems to indicate this is for the support of
>>>pppd. 
>>>   
>>>
>>>      
>>>
>>Nope, it is used by network support routines. So instead of having to
>>reimplement all the compression functions anew, we use libz.
>> 
>>
>>    
>>
>I dont understand, I searched the source for uses of "zlib.h" there are
>2 references:
>1. in c/src/lib/libbsp/powerpc/shared/bootloader
>    This contains its own implementation of zlib, which is a modified
>0.93 version?
>2. in cpukit/libnetworking/net/ppp-deflate.c
>   This is the only reference to the included zlib library which is
>installed.  Where else is it used?  Isnt this only for support of pppd,
>which a lot of targets wont use?
>
>  
>
>> 
>>
>>    
>>
>>>Neither of which are useful for me.  I already use zlib 1.2.3 and
>>>my zlib is customized, so i cant have both of these.
>>>   
>>>
>>>      
>>>
>>Any particular reason for doing so?
>> 
>>
>>    
>>
>Well, yes. Zlib 1.2.3 is bug fixed.  Also, we have patched it so it
>returns us status information through a decompress operation so we can
>show the progress of long unzip's, which the library doesnt do
>normally.  We change the headers, and because rtems is installing its
>own zlib headers, which we dont use, it creates potential confusion
>about which header is being used for the build.  I really dont see why a
>standard library like zlib is forced on a build of rtems, if its not
>required by the core OS.  It should be possible to build and install the
>core OS, without the "extra's" like httpd, ftpd, pppd, but especially
>"zlib".  At the least, there should be a configure option that says "use
>included zlib", or "use user provided zlib, and here is where to look
>for the headers".
>
>  
>
Then the zlib in RTEMS needs to be updated.  If you want your percentage 
complete
support in, then it needs to be submitted to the maintainers of zlib.  
If it gets merged there,
then I would see no reason to merge the same code in our code base until 
the next zlib release.


I don't think RTEMS should be encouraging modifications to the standard 
API of
a standard package.  We don't want to encourage differences between an 
RTEMS version
of a package and the standard version.

With that said, I don't see too much trouble with an option to disable 
zlib and pick up another
version.  Ignoring your case of adding functionality and assuming that 
the verison in RTEMS
were the latest, it is possible that you could have a version optimized 
for a particular CPU or
be deferring to some special ASIC for compression.

My biggest negative is that this is an option that would NEVER get 
tested since the standard
builds would never use it and I don't think any RTEMS maintainer would 
go out of their way
to exercise it.

>Steven
>  
>