WP-34S build problems on Linux

[Eric Smith]

When I try to build WP-34S on a 64-bit Linux platform (Fedora 14) using the CodeSourcery toolchain, I get several errors. The first ones are in post_process.c:

printf( "sizeof(struct argcmd) = %d\n", sizeof(struct argcmd) );

The sizeof() macro returns a value of type size_t, which may not fit in an int. The correct conversion (according to the ISO C standard) for printf is "%zu" rather than "%d".

The rest of the problems in that file are all like:

post_process.c:72:2: error: cast from pointer to integer of different size

Resulting from source lines like:

ADJUST( p_monfuncs,     monfunc );

The ADJUST macro is defined as:

#define ADJUST(p,type) (info->p = (struct type *) BUFF(info->p))

I haven't yet figured out how to fix this. It appears to me that the code does an fread() of data intended for the target machine (ARM) into a buffer, and depends on the pointer size and endianness of the build host matching that of the target, which is not a good assumption.

I used a workaround for that, and got another two more errors:

In file included from asone.c:26:0:

main.c: In function 'main':

keys.c:428:15: error: 'runmode' may be used uninitialized in this function

keys.c:429:15: error: 'alphas' may be used uninitialized in this function

I removed -Werror to try to get past that, and the linker tells me:

region `flash' overflowed by 520 bytes

Is there any feature I can easily remove/disable that is likely to reduce the ROM size by at least 520 bytes?

Is this the right place to discuss such problems? It didn't appear that the tracker on Sourceforge is being used.

Thanks!

Eric

Edited: 2 Oct 2011, 10:24 p.m.

[Paul Dale]

Quote:

---

When I try to build WP-34S on a 64-bit Linux platform (Fedora 14) using the CodeSourcery toolchain, I get several errors. The first ones are in post_process.c:

printf( "sizeof(struct argcmd) = %d\n", sizeof(struct argcmd) );

The sizeof() macro returns a value of type size_t, which may not fit in an int. The correct conversion (according to the ISO C standard) for printf is "%zu" rather than "%d".

---

I think the better fix would be casting the sizeof result to int which I'll commit soon. We build on machines with somewhat stupid compilers and I very much doubt they support %zu.

Quote:

---

The rest of the problems in that file are all like:

post_process.c:72:2: error: cast from pointer to integer of different size

...

I haven't yet figured out how to fix this. It appears to me that the code does an fread() of data intended for the target machine (ARM) into a buffer, and depends on the pointer size and endianness of the build host matching that of the target, which is not a good assumption.

---

This is one for Marcus. The post processor is packing pointers into flash into sixteen bits (128kb of flash where code must be even byte aligned means sixteen bits is sufficient for a function pointer). This is quite a hack but it saves more than a bit of flash :-)

Quote:

---

I used a workaround for that, and got another two more errors:

In file included from asone.c:26:0:

main.c: In function 'main':

keys.c:428:15: error: 'runmode' may be used uninitialized in this function

keys.c:429:15: error: 'alphas' may be used uninitialized in this function

---

These aren't errors fortunately. The compiler isn't clever enough to see that :-( I think I can fix this in a clean enough manner by avoiding the conditional assignment -- might save a couple of bytes too.

Quote:

---

I removed -Werror to try to get past that, and the linker tells me:

region `flash' overflowed by 520 bytes

Is there any feature I can easily remove/disable that is likely to reduce the ROM size by at least 520 bytes?

---

Try reducing the number of flash segment in the features.h header (NUMBER_OF_FLASH_REGIONS) or by turning off some functionality there. Matrix support is largish as are the zeta/Bernoulli pair. I've been adding more than a bit of matrix code recently.

- Pauli

[Eric Smith]

Got a binary built, thanks! I suppose I'll try flashing one of your premade ones first, to make sure the process works, before trying the image I just built.

[Marcus von Cube, Germany]

We've had a bad with the CodeSourcery compiler: It produced a hang in the firmware due to a compiler (code generation or optimization) error. Don't hope it will do the job.

post_process.c was designed to run on a Windows build machine. It relies on a structure output by the linker after the actual image where it finds the actual 32 bit addresses of the functions and the addresses of the function tables themselves. It makes some assumptions about the endianess and alignment of the host compiler as you already found out.

[Eric Smith]

So it's not currently possible to build on Linux?

[Marcus von Cube, Germany]

Check if Yagarto.de has a Linux build of GCC 4.6. Set the options in the Makefile for HOSTCC to force a 32bit build. If you compile under Linux with the same options as the build from us the binaries should be identical (except for the revision number).