search

boludoz / lz4

Automatically exported from code.google.com/p/lz4
Other
0 stars 0 forks source link

test fail on s390x #140

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. build and test on s390x. I paseted build log following.

-----
(sid_s390x-dchroot)iwamatsu@zelenka:~/lz4.svn.git/trunk$ make test
make[1]: Entering directory '/home/iwamatsu/lz4.svn.git/trunk/examples'
cc      -I..  -O3 -std=c99 -Wall -Wextra -Wundef -Wshadow -Wstrict-prototypes 
-Wno-missing-braces     ../lz4.c printVersion.c -o printVersion
cc      -I..  -O3 -std=c99 -Wall -Wextra -Wundef -Wshadow -Wstrict-prototypes 
-Wno-missing-braces     ../lz4.c blockStreaming_doubleBuffer.c -o doubleBuffer
cc      -I..  -O3 -std=c99 -Wall -Wextra -Wundef -Wshadow -Wstrict-prototypes 
-Wno-missing-braces     ../lz4.c blockStreaming_ringBuffer.c -o ringBuffer
cc      -I..  -O3 -std=c99 -Wall -Wextra -Wundef -Wshadow -Wstrict-prototypes 
-Wno-missing-braces     ../lz4.c blockStreaming_lineByLine.c -o lineCompress
./printVersion
Hello World ! LZ4 Library version = 10300
./doubleBuffer Makefile
inp = [Makefile]
lz4 = [Makefile.lz4s-8192]
dec = [Makefile.lz4s-8192.dec]
compress : Makefile -> Makefile.lz4s-8192
compress : done
decompress : Makefile.lz4s-8192 -> Makefile.lz4s-8192.dec
decompress : done
verify : Makefile <-> Makefile.lz4s-8192.dec
verify : NG
./ringBuffer   Makefile
inp = [Makefile]
lz4 = [Makefile.lz4s-0]
dec = [Makefile.lz4s-0.dec]
Verify : NG
./lineCompress Makefile
inp = [Makefile]
lz4 = [Makefile.lz4s]
dec = [Makefile.lz4s.dec]
Verify : NG
make[1]: Leaving directory '/home/iwamatsu/lz4.svn.git/trunk/examples'
make[1]: Entering directory '/home/iwamatsu/lz4.svn.git/trunk/programs'
cc      -I..  -O3 -std=c99 -Wall -Wextra -Wundef -Wshadow -Wstrict-prototypes 
-DLZ4_VERSION=\"r122\"  -DDISABLE_LZ4C_LEGACY_OPTIONS ../lz4.c ../lz4hc.c 
bench.c xxhash.c lz4io.c lz4cli.c -o lz4
cc      -I..  -O3 -std=c99 -Wall -Wextra -Wundef -Wshadow -Wstrict-prototypes 
-DLZ4_VERSION=\"r122\"  datagen.c -o datagen
./datagen -g16KB  | ./lz4 -9     | ./lz4 -vdq > /dev/null
*** LZ4 Compression CLI 64-bits r122, by Yann Collet (Sep 16 2014) ***
Successfully decoded 16384 bytes                                               
./datagen         | ./lz4        | ./lz4 -vdq > /dev/null
*** LZ4 Compression CLI 64-bits r122, by Yann Collet (Sep 16 2014) ***
Error 79 : Error : invalid stream checksum detected
Makefile:140: recipe for target 'test-lz4' failed
make[1]: *** [test-lz4] Error 79
make[1]: Leaving directory '/home/iwamatsu/lz4.svn.git/trunk/programs'
Makefile:166: recipe for target 'test' failed
make: *** [test] Error 2
-----

What version of the product are you using? On what operating system?

r117 is no problem. We can see this problem from r118. 

Please provide any additional information below.

Original issue reported on code.google.com by iwama...@gmail.com on 16 Sep 2014 at 4:05

GoogleCodeExporter commented 9 years ago 
I'm suspecting an endian detection problem,
although it's unclear why r118 should be more affected that r117
since the endian detection code has not evolved between those 2 versions...

Could you check that hypothesis by manually forcing endian mode ?
Look for LZ4_BIG_ENDIAN define, and manually override its value please.

Regards

Original comment by yann.col...@gmail.com on 16 Sep 2014 at 4:37

GoogleCodeExporter commented 9 years ago 
I'll look into it.

Original comment by yann.col...@gmail.com on 16 Sep 2014 at 4:40

GoogleCodeExporter commented 9 years ago 
I created a patch which revise this problem.
I attached.

Original comment by iwama...@gmail.com on 16 Sep 2014 at 4:41

Attachments:

GoogleCodeExporter commented 9 years ago 
Hi,

Thanks for your comment.
This is caused by bit size.
s390x is 64bit not 32bit.

Original comment by iwama...@gmail.com on 16 Sep 2014 at 4:43

GoogleCodeExporter commented 9 years ago 
OK thanks, so it was the 64-bits detection macro.

I'll correct it for next release.

And when that's possible, 
I would also like to get rid of detection macro completely, 
relying instead on runtime detection which are much more reliable
(but still trigger some linking errors currently ...)

Original comment by yann.col...@gmail.com on 16 Sep 2014 at 4:45

GoogleCodeExporter commented 9 years ago 
Indeed.

However, I think that we cannot avoid this problem when we support C library of 
many  versions and many CPU's.
But I think about a method to do macro briefly.

Thanks!

Original comment by iwama...@gmail.com on 16 Sep 2014 at 4:52

GoogleCodeExporter commented 9 years ago 
Latest "dev" branch release supports your proposed improvement :

https://github.com/Cyan4973/lz4/tree/dev

For your testing

Original comment by yann.col...@gmail.com on 22 Sep 2014 at 4:39

GoogleCodeExporter commented 9 years ago 
Fixed into r123

Original comment by yann.col...@gmail.com on 25 Sep 2014 at 8:41