WP-34S build problems on Linux



#2

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.


#3

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


#4

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.

#5

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.


#6

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


#7

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).


Possibly Related Threads...
Thread Author Replies Views Last Post
  Is Linux common among us RPN types? db (martinez, ca.) 46 4,646 12-11-2013, 08:25 PM
Last Post: Paul Guertin
  [WP-34S] Unfortunate key damage with update to V3 :( svisvanatha 5 963 12-10-2013, 11:37 PM
Last Post: Les Bell
  WP-34S (Emulator Program Load/Save) Barry Mead 1 534 12-09-2013, 05:29 PM
Last Post: Marcus von Cube, Germany
  DIY HP 30b WP 34s serial flash/programming cable Richard Wahl 2 754 12-04-2013, 11:14 AM
Last Post: Barry Mead
  EMU41; Dosbox on Linux; Excruciatingly sloooow Geir Isene 9 1,097 12-01-2013, 05:10 PM
Last Post: Geir Isene
  WP 34S/43 ?'s Richard Berler 3 682 11-10-2013, 02:27 AM
Last Post: Walter B
  My FrankenCulator (wp-34s) FORTIN Pascal 4 699 11-09-2013, 06:18 PM
Last Post: FORTIN Pascal
  WP 34S Owner's Handbook Walter B 5 916 11-09-2013, 05:34 PM
Last Post: Harald
  wp 34s overlay and programming. FORTIN Pascal 6 939 11-08-2013, 01:28 PM
Last Post: Nick_S
  m.dy in display of WP-34S Harold A Climer 3 581 11-05-2013, 11:28 AM
Last Post: Andrew Nikitin

Forum Jump: