undefined symbol: rand

[mark_melvin]

Hey Guys,

I am trying to build a native module following this page of documentation:

https://docs.micropython.org/en/latest/ ... tml#natmod

And I get the following LinkerError:

Code: Select all

LinkError: build/../cc-slave/src/handshake.o: undefined symbol: rand
../../micropython/py/dynruntime.mk:138: recipe for target 'build/modcc.native.mpy' failed
make: *** [build/modcc.native.mpy] Error 1

I'm sure I've built this code as an embedded module before. Does anyone have any idea why this is not resolving when building this way?

Thanks,
Mark

[stijn]

Just tried and same problem. Looked around for a bit but I don't immediately see a way to pass e.g. glibc to the linker script so it knows the symbol is an external one.

[mark_melvin]

Thanks for the reply. I have a similar question when trying to create a dynamic module using the native machine code approach. My native code expects a C function for timing to be externally defined (void delay_us(void)). This is hardware specific and I can't seem to figure out how to delegate this to the mp_hal_* implementation of the function.

Is this possible? If so, could someone help with an example?

Finally, is it possible to define a function in Python (that gets embedded into this native .mpy module), but call that Python-defined function from the native C code? Maybe via some magical name/extern'ing of a wrapper? I am thinking probably not, but perhaps I just don't fully understand the machinery.

[mark_melvin]

Basically, I am trying to leverage an existing C library that relies on a few external functions to be defined related to a fundamental delay in microseconds, configuring and starting a timer, and implementing callbacks. It would be nice to use the dynamic native module infrastructure but it looks like this is pushing that mechanism a little too far. As I see it my options are:

1. Use the native module (if indeed possible)
2. Compile my own custom micropython with a custom module
3. Port this C library to pure (micro)Python

I'm kind of inclined to just go with #3 if #1 is not feasible. I sort of prototyped #2 awhile back and it seemed to work, but I had to modify some of the internals of the STM32 port (which may not be required if I knew more..) and maintaining a custom micropython seems like more of an inconvenience going forward.