Solaris sparc build problems
F111 - Failure Feedback Forum
Using vlerqtcl-2006-12-06.tar.gz, I'm had problems compiling on sparc solaris.
I had a problem with int64_t being undefined in the column.h portion of vlerq.c. I found that adding '#include <unistd.h>' to line 12 of vlerq.c fixed that.
I also had a problem with _BIG_ENDIAN on my system defined to something that isn't valid in a #if expression (looks like it is defined as empty string). I fixed this by adding:
#if WORDS_BIGENDIAN #define _BIG_ENDIAN 1 #endif
Compiling succeeded, but tests failed due to alignment issues (I'm pretty sure). So I added:
#ifdef __sparc__ #define VALUES_MUST_BE_ALIGNED 1 #endif
Now I get compile errors in the VALUES_MUST_BE_ALIGNED versions of the getter functions. I started fixing these, but got stuck on one in Getter_i32 and Getter_i64:
item->c[i] = ptr[i];
The c field is not an array or pointer and I'm not sure what this should be.
Summary
Several portability bugs fixed w.r.t. Solaris/SPARC, which is big-endian and which requires all word accesses to be aligned to their natural widths.
Fixes now in darcs, some tests added to basic.test to detect alignment problems earlier on.
Imported
Thanks, that catches a lot of issues which regressed from vlerq3 - I see I forgot to check several details. Here's a copy of vlerq.c which should fix things for Solaris: <a title="File uploaded at Dec 11/2006 04:24PM" href="files/3223.gz"><img border=0 alt="Document Icon" src="styles/doc.gif">vlerq.c.gz</a>
Great, it compiles. Now I get a crash in test 26 of emit.test:
Program received signal SIGSEGV, Segmentation fault. #0 0xff15e594 in CoerceColType () #1 0xff15ea10 in CoerceColumn () #2 0xff15c774 in DefCmd_OO () #3 0xff1612a0 in VlerqObjCmd ()
Is that enough clues to figure out the problem?
Hm, I suspect an alignment issue - saves were not implemented in C in v3. Please try the following: in vlerq.c locate the CoerceColType line. Then inside, there's a switch case which contains:
case IT_wide:
result = InitColumn(count, PickIntGetter(64), 8 * count);
for (i = 0; i < count; ++i) {
item.c = column;
obj = ItemAsObj(&item, GetItem(i, &item));
if (!CastObjToItem('L', obj, &item))
Tcl_Panic("cct-L?");
((int64_t*) result.seq->data[0].p)[i] = item.w;
}
break;
Before that last assignment, add:
Assert(((int) result.seq->data[0].p) % 8 == 0);
I suspect that it will fail, which is a problem when mis-alignment is not handled by hardware.
I'll look for a portable alternative if this is indeed the problem.
Yep, that's most likely it. You can work around this for now by adding a dummy field in the struct Sequence definition - just add "void *dummy;" after the line:
Cleaner cleaner; /* called during cleanup */
The "void *dummy" workaround fixes the crash. Now I only get a few "asview" failures, but those can be ignored because the vlerq.c is now slightly out of synce with the test files. So it looks good, thanks.
FYI, I've changed the portability code a bit more, am now using "stdint.h" - if WORDS_BIGENDIAN is a built-in define on SPARC then this should still all work.
WORDS_BIGENDIAN comes from ./configure, so it should work for all TEA based builds.
