After opening bplsparkle.so in Linux and compiling the debug version, I followed the error messages and found that the fail occure in the call on Sparkle.Middleware.Compress.pas:line 278 where lines call directly deflate(FZstream, zfinish) in the ines:
while ZCompressCheckWithoutBufferError(deflate(FZStream, Z_FINISH)) <> Z_STREAM_END do
begin
FStream.WriteBuffer(FBuffer, Length(FBuffer) - Integer(FZStream.avail_out));
And on line 291 there is a direct call to deflateend(FZstream);
When expanding the system.zilib.pas and press F1 on the commands, help for for system.Zlib.deflate tate explicitly the the unction call if for internal use only and
When the gzip internal method of an external library, shouldn't that always flagged as an error, also when comompiling for win32 or any of the other platforms ??
Maybe there is a need for a new error message?
Illegal call to an internal method inside an external library ?
I don't think that's a problem. The documentation says it's for internal only simply because it's a more low level function. It's pretty much valid ZLib method that is called by the ZLib unit itself.
It works on Windows and also worked on Linux until a recent minor Delphi update which got broken. It even works on Debug config but not on Release config. It's plain and simple a Delphi bug that should be fixed.
For my part, the release version compiles fine, but the debug version fails in the flush method:
procedure TXDataCompressionStream.Flush;
begin
FZStream.next_in := nil;
FZStream.avail_in := 0;
try
if FStream.Position <> FStreamPos then FStream.Position := FStreamPos;
while ZCompressCheckWithoutBufferError(deflate(FZStream, Z_FINISH)) <> Z_STREAM_END do
begin
FStream.WriteBuffer(FBuffer, Length(FBuffer) - Integer(FZStream.avail_out));
FZStream.next_out := @FBuffer[0];
FZStream.avail_out := Length(FBuffer);
end;
if Integer(FZStream.avail_out) < Length(FBuffer) then
begin
FStream.WriteBuffer(FBuffer, Length(FBuffer) - Integer(FZStream.avail_out));
end;
finally
deflateEnd(FZStream);
end;
end;
Maybe both bug reports would have been solved if Calvin Tang or other involved from Embarcadero had been provided with complete description of where bug occures, like let them install the needed components of the Biz packge so they could test the above function of why it fails.
If adding system.zlib to the two function names, all compiles ok
procedure TXDataCompressionStream.Flush;
begin
FZStream.next_in := nil;
FZStream.avail_in := 0;
try
if FStream.Position <> FStreamPos then FStream.Position := FStreamPos;
while ZCompressCheckWithoutBufferError(system.ZLib.deflate(FZStream, Z_FINISH)) <> Z_STREAM_END do
begin
FStream.WriteBuffer(FBuffer, Length(FBuffer) - Integer(FZStream.avail_out));
FZStream.next_out := @FBuffer[0];
FZStream.avail_out := Length(FBuffer);
end;
if Integer(FZStream.avail_out) < Length(FBuffer) then
begin
FStream.WriteBuffer(FBuffer, Length(FBuffer) - Integer(FZStream.avail_out));
end;
That's definitely something we can modify in source code. If it works around the compilation problem, it would be great. We will include it in next release.
Solution that worked for me. Under Debug configuration - Linux 64-bit platform, I turned off "Use debug .dcus" and it compiled without problems in debug mode.
