Trouble in linking pic24 port of v10

[Brad Minch]

Hi everyone,

As I have mentioned, I am hoping to get a pic24 port of v10 up and running.  Rather than starting with Bryan Jones' pic24 port from v09, I am trying to start with the v10 posix64 platform (although I am certainly attempting to benefit from his earlier port).  For the time being, I have not implemented a plat_loadCodeObject function.  Once I understand things a bit better, I am hoping to implement one that loads marshaled modules from a micro SD card.  The main.py and main.c are taken directly from the posix64 platform (i.e., main.py just imports and runs ipm).  When I attempt to build the pic24 platform that I have made, I get the following warning when it builds marshal.c:

src/platform/pic24/build/vm/marshal.c: In function 'load_int':

src/platform/pic24/build/vm/marshal.c:53: warning: left shift count >= width of type

src/platform/pic24/build/vm/marshal.c:53: warning: left shift count >= width of type

During the final linking step, it gives me the following undefined reference errors to marshal_load and marshal_dump in pm_generated_objs.o:

src/platform/pic24/build/pm_generated_objs.o(.text+0xbbe): In function `no131':

/Users/bminch/Code/python-on-a-chip/src/platform/pic24/build/pm_generated_objs.c:66: undefined reference to `marshal_load'

src/platform/pic24/build/pm_generated_objs.o(.text+0x12a4): In function `no217':

/Users/bminch/Code/python-on-a-chip/src/platform/pic24/build/pm_generated_objs.c:46: undefined reference to `marshal_load'

src/platform/pic24/build/pm_generated_objs.o(.text+0x12d8): In function `no218':

/Users/bminch/Code/python-on-a-chip/src/platform/pic24/build/pm_generated_objs.c:68: undefined reference to `marshal_dump'

Both of these functions are certainly present in marshal.c and prototyped in marshal.h, and marshal.o was included when the static library archiver created libpmvm.a.  Does anyone have any ideas about what might be going on here?

Thanks,

Brad.

[Dean Hall]

Posix64 is for a 64-bit architecture. Start with plain posix for 32-bit.  I believe posix64 has some configuration items set for 64-bit that are causing your compile error.

!!Dean

--
--
You are subscribed to the "python-on-a-chip" (or p14p for short) Google Group.
Site: http://groups.google.com/group/python-on-a-chip
 
---
You received this message because you are subscribed to the Google Groups "python-on-a-chip" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python-on-a-ch...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Bradley Minch]

Hi Dean,

In comparing the posix and posix64 platform files, the only three differences that I can find are as follows:

1. In main.c, HEAP_SIZE is defined to be 0x2000 for posix and 0x4000 for posix64.

2. In plat.h, the posix64 platform has PM_PLAT_POINTER_SIZE defined to be 8 whereas the posix platform does not define this.

3. In plat.c, the posix64 platform includes a plat_loadCodeObject function and registers it in the plat_init function whereas the posix platform does neither.

I had already commented out the PM_PLAT_POINTER_SIZE in my plat.h file.  Likewise, I had already removed the plat_loadCodeObject function from plat.c and commented out the line that registers the plat_loadCodeObject function from my plat_init function.  That leaves the difference in the HEAP_SIZE definition.  I just tried rebuilding with HEAP_SIZE defined as 0x2000 instead of 0x4000 with the same results as before.  Was there something else different about the posix64 platform that I might have missed?

Brad.

[Bradley Minch]

Hi everyone,

After a few hours of quality time with Google, I ran across this, which suggested the following solution to a similar sounding problem:

The trick here is to put the library AFTER the module you are compiling. The problem is a reference thing. The linker resolves references in order, so when the library is BEFORE the module being compiled, the linker gets confused and does not think that any of the functions in the library are needed. By putting the library AFTER the module, the references to the library in the module are resolved by the linker.

The linker command that scons generated had put libpmvm.a before pm_generated_objs.o.  I manually tried the same command only with libpmvm.a last on the command line and it linked without any problems.  Then, I changed the line in the SConscript file that builds main from

main = env.Program("main", [mapfile, platform_c_sources + pmvm_lib,

                           "#src/platform/posix64/build/pm_generated_objs.c"])

to

main = env.Program("main", [platform_c_sources, 

                           "#src/platform/pic24/build/pm_generated_objs.c", 

                           pmvm_lib])

causing scons to put libpmvm.a last on the link command line.  The build now proceeds from start to finish without any errors.  I still have the warning that I mentioned in my original post, but at least the thing builds.

Brad.

[Dean Hall]

My previous message I was at work (not at my p14p workstation), so my insight was limited.
Yes, the PM_PLAT_POINTER_SIZE was what I was thinking of. That is the full extent of the differences.
Great! Thanks for finding that scons issue.
I see the cause of your compiler warning.
I will file and fix these last two issues.

!!Dean

[Dean Hall]

Both issues resolved & pushed. Let me know if they don't work (I don't use the PIC compiler).

https://code.google.com/p/python-on-a-chip/issues/detail?id=248
https://code.google.com/p/python-on-a-chip/issues/detail?id=249

!!Dean

On May 22, 2013, at 5:24 PM, Bradley Minch wrote:

[Bradley Minch]

Hi Dean,

I got the updated code from the repository and the issues appear to have been resolved.  I actually got another compiler warning during the build of sli.c, but it did not seem to be as big a deal.  The warning was as follows:

src/platform/pic24/build/vm/sli.c: In function 'sli_ltoa10':

src/platform/pic24/build/vm/sli.c:164: warning: this decimal constant is unsigned only in ISO C90

Brad.