Waiting for cf.sourceforge.net

ethan on 2002-12-03T09:10:44

Uah. The below observed on sunos sunu991 5.8 generic_108528-14 sun4u sparc.



This is an error report generated automatically by CPANPLUS, version .

Below is the error stack during 'make test':

make[1]: Entering directory `/net/sunu991/disc1/.cpanplus/5.8.0/build/MP3-Mplib-0.01/mplib' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/net/sunu991/disc1/.cpanplus/5.8.0/build/MP3-Mplib-0.01/mplib' PERL_DL_NONLAZY=1 /usr/local/perl/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/t1....ok t/t2....ok t/t3....# Failed test (t/t3.t at line 46) # Failed test (t/t3.t at line 48) # Failed test (t/t3.t at line 50) # Failed test (t/t3.t at line 52) # Failed test (t/t3.t at line 54) # Failed test (t/t3.t at line 56) # Failed test (t/t3.t at line 63) # Failed test (t/t3.t at line 65) # Looks like you failed 8 tests of 21. dubious Test returned status 8 (wstat 2048, 0x800) DIED. FAILED tests 12-17, 20-21 Failed 8/21 tests, 61.90% okay t/t4....ok t/t5....ok Failed Test Stat Wstat Total Fail Failed List of Failed ------------------------------------------------------------------------------- t/t3.t 8 2048 21 8 38.10% 12-17 20-21 Failed 1/5 test scripts, 80.00% okay. 8/76 subtests failed, 89.47% okay. make: *** [test_dynamic] Error 29



In my interpretation that means that only one function is not behaving properly, namely the one turning an id3v2-tag into a Perl hash which is a good thing. Still I am now condemned to wait for my login for Sourceforge's compile farm to try this beast under several other operating systems, including MacOSX, FreeBSD and different flavours of Sparcs.

I can already log into the OS-switch menu, but my account doesn't yet seem to have propagated to the actual machines behind that. I can only hope that they have Perl and vim installed.

Also, the above tests were made using gcc instead of Sun's legacy compiler. The available compilers is yet another uncertainty.

Yet, I have the hope that once my module works fine under two operating systems, changes should increase that it also works under the third and fourth and so on.

How do other people ensure interoperability for various OSs? Do they have accounts for different machines or is it programmer's experience that makes the thing work on most platforms?


Ensuring portable code

nicholas on 2002-12-03T12:05:51

How do other people ensure interoperability for various OSs? Do they have accounts for different machines or is it programmer's experience that makes the thing work on most platforms?

A bit of both. There's no substitute for testing on different machines (and with different compilers), but you'll have a lot less problems if the first place once you become experienced in what is and isn't portable

Part of the problem with portability is that the most common platform (x86) is one of the most forgiving (little or no alignment contraint on pointers, no structure padding), and the most common compiler (gcc) is similarly lax. Bondage and discipline is good for you, but sadly they are not even the implicit default.

For example, your module is also failing its tests on PPC linux, so I'd suspect that it's an endian-ness bug somewhere (your code, or the included library), as both sparc and PPC are big endian. (ie I'm guessing that your code and the library is mostly tested on x86). If it had passed on sparc, but failed on PPC (and ARM; usually little endian) then my guess would be that it woudl be a plain char issue (char is unsigned on PPC and ARM, signed just about everywhere else.)

The you start to get to more esoteric stuff, such as what happens when you ask for a logical shift larger than the integer (undefined behaviour in C, this might actually be your probkem here), or signed integer arithmetic overflows (undefined behaviour, but it turns out that it will do what you expect, if you think it should just do 2s complement, on most platforms except for 64 bit Irix and UTS), whether sizeof(long) isn't sizeof(int), whether a pointer is larger than int, whether sizeof(short) isn't 2 (on Crays it is 8), how bitfield ordering works, is '\n' actually 10, is 'A' > '1', etc

B&D

koschei on 2002-12-03T12:55:35

What options would you recommend to gcc to improve its B&D on the code?

Endianness

ethan on 2002-12-03T14:06:04

For example, your module is also failing its tests on PPC linux, so I'd suspect that it's an endian-ness bug somewhere (your code, or the included library), as both sparc and PPC are big endian.

Seems more and more reasonable to me to suspect byte order. Just browsed through mplib and did in fact find a lot of bitshift operations in mp_get_id3v2_tag (the id3v2-reading was the stuff that failed in the tests) but not in the corresponding mp_get_id3v1_tag.

If these are in fact the offending parts, a few preprocessor directives could already be enough to differentiate between big and little endianness.

The mplib docs don't say much abou that. They only mention mplib being "cross-platform capable" which is probably a broad term. Fortunately the library comes with its own testsuite which is the first thing I will try when I finally have the access to the compile-farm.

B & D with gcc

nicholas on 2002-12-03T14:06:08

This is use.perl, so -Wall, obviously :-)

parrot is compiled with -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Waggregate-return -Winline -W -Wno-unused -Wsign-compare -Wformat-nonliteral -Wformat-security -Wpacked -Wpadded -Wdisabled-optimization on gcc 3.2. Some of those are specific to various recent versions of gcc - take a look at parrot's config/auto/gcc.pl for how it chooses its bondage preferences based on gcc version. However, parrot is trying really hard from the start to build under maximum bondage. Even with recent effort, the perl5 core isn't much mor than -Wall clean.

Annoyingly as far as I'm aware all the gcc options can only warn you about problems based on the platform you're compiling for, so it can't tell you about portability-removing assumptions you've made (such as the pointer cast alignment warnings only warn about the target platform, so you won't get warned that maybe casting a char * to a double * might be a bad plan) and IIRC on some of the strict ANSI settings it still lets through some non ANSI C if it's flagged in a special way (so you can't verify that glibc's headers really are ANSI, unless you use a stricter compiler, such as lcc)