-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Cross-compiling matplotlib and dependencies for OpenWRT fails on import matplotlib.pyplot #9244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Additionally, libfreetype was compile with the following options:
|
Can you try against either |
you need to apply this patch locally I think #9074 |
Same results. Patch 9074 + V2.0.2
Patch 9074 + V2.1.x @ f2c8fae
|
Do you have instructions on how to reproduce your setup, possibly using docker? (would something like https://wiki.openwrt.org/doc/howto/docker_openwrt_image work?) (e.g., how did you install python etc.) |
Python / matplotlib / etc are all compiled into the firmware image. I had to add a missing package to LEDE 17.01.02 (numpy), and add in python3 support for others (pytz, pyparsing, dateutil, cycler, and six), but everything else is stock in the build environment (including both libfreetype and libpng). This is all based on the commit tag "v17.01.2" for the LEDE project (last major release). I attempted to build for docker (x86 architecture), but testing here shows as success in loading matplotlib.pyplot (no errors in freetype). Note that the original target is the BRCM 2708 (Raspberry Pi 3). This seems to point that there is some possible issue in cross-compiling for ARM architectures, and passing down the flags appropriately (should happen transparently in buildroot systems). See below for the makefile:
Added patch to modify the destdirs to point to the arm compiled packages:
I'm attempting a QEMU ARM image now, and will upload with success. Else, I have a Raspberrry Pi 3 image ready to go at any time. Am I able to directly upload the firmware images here? |
tbh I'm not super familiar (actually, not at all) with the general docker ecosystem, but I guess you can use https://quay.io/ similarly to https://github.com/pypa/manylinux (which is the only image I've interacted with so far :p). |
Issue is not with the docker. A docker image (compiled against x86, which is the native build environment) architecture works just fine for loading in matplotlib,pyplot, which makes it seem that this is an issue with cross-compiling to an ARM architecture. Docker is not a real virtual machine, that is the architecture in the docked image must match that of the host. Thus why I am trying to compile against a QEMU arm virtual machine to see if I have any success there in re-creating the error. For more on armvirt: |
Just to be clear, I don't think I have the knowledge to test a full VM. |
How about I put my Raspi somewhere publicly accessible with the build on it? That way you can just ssh into the box for access, and do all your testing there. |
Go for it. email me to firstname.lastname@berkeley.edu |
Sent an email. |
Determined the root issue after instrumenting the code a bit. The font list cache file (fontList.json) is not being generated. See failure below. It seems a similar issue was found in #5406, but no resolution was really added there.
|
Actually the error occurs while trying to open the not-yet-existent cache (which should normally trigger a normal exception that leads to the file being generated). ret = PyObject_CallMethod(file, (char *)"seek", (char *)(MPL_OFF_T_PYFMT "i"), position, 0); ? /* Do some error checking instead of trusting OS 'seek()'
** error detection, just in case.
*/
if ((whence < 0 || whence >2)
#ifdef SEEK_HOLE
&& (whence != SEEK_HOLE)
#endif
#ifdef SEEK_DATA
&& (whence != SEEK_DATA)
#endif
) {
PyErr_Format(PyExc_ValueError,
"whence value %d unsupported", whence);
return NULL;
} but looking at the mpl code it looks like whence should be zero. Can you check that this is indeed where the error happens? That somehow an invalid value of 217555 reaches _io__Buffered_seek_impl? (Yes that probably means recompiling cpython, if you can't get gdb to work...) |
Hello, i'm trying to compile the matte run on LEDE and the x86-64 platform, version 1.4.3 is seamless and everything works from 1.5.3 I have a similar problem in compilation. Can you expose your compilation packages to matplotlib? Thank you, zbynek Kocur |
Thank you @jwbrack , i will try it. |
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help! |
Especially with the move to pybind11 the situation likely changed; let's close this and track this on a new issue if needed. In particular, in 97477d7 the line that throws the exception mentioned originally was removed; now we call PyErr_WriteUnraisable if an error occurs in the file close. |
Bug report
Bug summary
When cross-compiling matplotlib and dependencies (numpy, six, pytz, etc) for OpenWRT in Ubuntu 16.04LTS, all code properly compiles. However, when testing matplotlib on the target, when importing matplotlib.pyplot I get the failure "terminate called after throwing an instance of 'char const*'". Specifically, after a font is imported in font_manager, the failure comes up when attempting to add a second font (regardless of the first font). I've attempted multiple versions of Python3 (3.6.2, 3.6.0, 3.5.4), as well as numerous combinations of dependent packages. Not that I am only compiling freetype as a library for the shared object "libfreetype.so.6*", as well as the ft2font header file, instead of the full freetype package.
Code for reproduction
Actual outcome
Expected outcome
Matplotlib version
The text was updated successfully, but these errors were encountered: