Page 1 of 1
undefined symbol: rand
Posted: Sat Dec 28, 2019 11:38 pm
by 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
Re: undefined symbol: rand
Posted: Sun Dec 29, 2019 7:29 pm
by 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.
Re: undefined symbol: rand
Posted: Sun Dec 29, 2019 9:15 pm
by 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.
Re: undefined symbol: rand
Posted: Mon Dec 30, 2019 12:56 am
by 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:
- Use the native module (if indeed possible)
- Compile my own custom micropython with a custom module
- 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.