New tools and 4.6.99.3

[Steven Johnson]

Ralf Corsepius wrote:

>On Tue, 2006-05-02 at 11:57 +1100, Steven Johnson wrote:
>  
>
>>Joel Sherrill wrote:
>>
>>    
>>
>>>Steven Johnson wrote:
>>>
>>>      
>>>
>>>>Ralf Corsepius wrote:
>>>>
>>>>        
>>>>
>>    
>>
[snip]

>>>Then the zlib in RTEMS needs to be updated.  
>>>      
>>>
>>This may be so, but the difficulty here will be unless a new version of
>>rtems is released every time a new version of zlib is released,
>>    
>>
>Wrong. 
>
>Only security sensitive changes and major bug fixes to zlib are of
>relevance. Anything else is versionitis.
>  
>
I think we actually agree on this point, but I wont dwell on it. 
However, in case you didn't already know, the zlib.net site states:
"Version 1.2.3 eliminates potential security vulnerabilities in zlib
1.2.1 and 1.2.2, so all users of those versions should /upgrade
immediately/."  I don't know what those vulnerabilities are, or if they
would impact on the use RTEMS puts the library to, but I thought I
should at least mention there are some apparent security problems, FYI.

>  
>
>> there
>>will always be times when the version in rtems isn't the latest.
>>    
>>
>Yes, ... and, where is the problem?
>
>The zlib version 
>... in GCC won't be the latest, either, nor will others be.
>... nor will the networking stack in RTEMS be in sync with that in
>FreeBSD.
>... nor will your development's machine's zlib be in sync with "bleeding
>edge zlib".
>...
>
>There is no reason for always wanting to use the "latest version"
>
>  
>
I agree with this also.

>>I don't think my patches would be very acceptable to the zlib
>>maintainers, because they introduce a measurable net decrease in
>>decompress speed, which for us is acceptable, but in the main people
>>seem to want a zlib thats as fast as possible. We put up with the
>>decrease because it means we get feedback during the ~8-10 minutes it
>>takes to decompress, whereas without it, we get no feedback and it takes
>>~7-9 minutes to decompress.
>>    
>>
>Then YOU have a system integration problem
>  
>
True, but I deal with it by having my own version of ZLib, which wont
always be the latest, but just happens to be at the moment, because of
the development cycle I'm currently in.  And I don't want to burden
anyone with my changes as they are of little use to others, but
essential to me.  I fully understand and accept the problem I have.

>  
>
>>>With that said, I don't see too much trouble with an option to disable
>>>zlib and pick up another version.
>>>      
>>>
>Please implement this yourself - 
>
I would if I could. Ive tried on a number of occasions to get
autoconf/automake stuff to do what I want (apart from trivial
modifications to what already exists).  Its obvious I have a mental
block about the autotools and just cant seem to work them out or get
them to behave if I try to change the way a ./configure system works in
any significant way.  Its not something I'm going to harp about however,
I've already said I've gotten around the problem for myself by deleting
the rtems installed zlib.a and zlib headers.  So for myself, problem
solved.  If the rtems developers see no difficulty in including zlib in
the source tree, I'm happy to live with that decision.

>I guess you both still have not
>understood how much depends on zlib:
>  
>

Hmmm, I'm honestly trying to understand,

>It's the whole network stack, not only pppd, and it is being used by
>bootloaders and many other useful tools and components.
>  
>
are we talking about the same RTEMS 4.6.99.3 as released a few days
ago?  Ive done several scans of the code, and I cant find any references
to "inflate", "deflate" or "zlib.h" in the zlib V1.2.2 library outside
of pppd. 

I do find reference in one "powerpc bootloader" to A zlib, but it uses a
completely different version [a version modified or derived from 0.95],
not the V1.2.2 library in discussion here.

Please point me to the other references.  The answer to this is the
critical issue for me, because I need to know if the other areas of the
rtems networking stack that use zlib (that I cant find) will work with
my customized version of zlib without error.  If not, then I need to
change my customized version so it will work ok with the rtems network
stack.

Thanks for the help.

Steven