I've got a solution to some of the alignment problems in wrc for sparc-solaris, but I wanted to bounce them off the -devel list before submitting a patch. I'm going to describe the problem first, and then my solution to it.
Sparc-solaris machines are a little pickier about byte alignment than x86-linux machines are (don't know about x86-solaris - haven't played with it). Basically things like ints need to be aligned on word boundaries, or else you get a bus error when you try to access them. The following code fragment:
struct myStruct { int a; int b; };
int main() { int tmp = (int) malloc(sizeof(struct myStruct)+2); tmp += 2; struct myStruct *myS = (struct myStruct *) tmp; myS->a = 0x12345678; return 0; }
Causes a bus error on the assignment into myS->a. Commenting out the tmp += 2 line of course solves the problem.
Unfortunately this kind of thing is happening in a few places in wrc/newstruc.c - in calls to convert_bitmap. The actual bitmap data is 22 bytes into the raw data from the resource file. The raw data is properly aligned on a word boundary, but the bitmap data isn't. The current process is to call convert_bitmap on the data, and then memcopy/memmove it into it's final resting place. The final resting place *is* word-aligned.
The solution I've taken in my code is to reverse the order - first I memcopy/memmove the bitmap data, and *then* I call convert_bitmap. This seems to solve the problems on sparc-solaris, and I can't see how it could hurt on Linux (but I haven't had a chance to test it on Linux yet).
Does this make sense? Does anyone have a better suggestion?
Warren