MicroPython Forum (Archive)

Hi,

If I build using the ./unix make and cygwin the build works but I get
the following linker warnings:

LINK micropython
/usr/bin/ld: symbol `ffi_type_pointer' missing from main hash table
/usr/bin/ld: symbol `ffi_type_sint32' missing from main hash table
/usr/bin/ld: symbol `ffi_type_sint64' missing from main hash table
/usr/bin/ld: symbol `ffi_type_sint8' missing from main hash table
/usr/bin/ld: symbol `ffi_type_uint32' missing from main hash table
/usr/bin/ld: symbol `ffi_type_uint64' missing from main hash table
/usr/bin/ld: symbol `ffi_type_uint8' missing from main hash table
/usr/bin/ld: symbol `ffi_type_void' missing from main hash table

If I build using the ./windows make and cygwin the build fails:

LINK micropython.exe
/usr/bin/ld: cannot find -lmman
collect2: error: ld returned 1 exit status
../py/mkrules.mk:72: recipe for target 'micropython.exe' failed
make: *** [micropython.exe] Error 1

Can someone tell me what the preferred tool chain is for building mincropython.exe is on Windows.

Cheers, Steve

As README suggests, to build unix/ you either need to have libffi developement files installed, or disable building against it.

windows/ once was supposed to be built with mingw32, but likely bitrotted since then.

pfalcon wrote:windows/ once was supposed to be built with mingw32, but likely bitrotted since then.

Is there anything Travis-alike that we can use to test the windows version of uPy?
How "officially supported" is the windows port, or should it be considered as deprecated / super-low-priority?

Well, it was just 1-2 patches to duplicate code from unix port, submitter didn't address issues raised, so that's it. I don't think it makes sense to call it "deprecated" - nice to be portable everywhere, but priority depends on its users' patch submission I guess...

Okay, turns out I still have mingw32 crosscompiler installed. So, I unbroke windows build. Caveat: it starts up in interactive mode, but faults on running scripts. Patches welcome .

Just to clarify: it faults under Wine. Not tested under native Windows.

The fault on running scripts might be due to the unix/main.c expecting a path with forward slashes, can you check if that is the problem?

As I mentioned in review comments, all paths are forward slashes (the others are not really paths ). The faults are saw were related to NLR (like NLR stack underflow and just segfaults).

It does not matter what slashes you are using. On windows _fullpath() returns backslashes, always. So whatever you use as file argument, it will crash when passing it a file argument. And that yields NLR faults. Now I didn't check with wine, but if it's implementation of _fullpath() is like the one on windows the behaviour would be exactly the same. And that happens to be the behaviour you are witnessing.

Thanks, it's always helpful to have good description, rather than read between the lines. But I still don't get how you got from backslashes to NLR failure - segfault from NULL on strchr('/') should not cause NLR fault (at least directly). Well, I'll leave that to you.

And we discussed in pullreq comments best practices to deal with that - please have windows/lib.c (or whatever name you have good reasons for) to implement realpath() for Windows, with POSIXy behavior.