Created attachment 4511 [details] Patch to fix Python/configure.ac Building of python3 will fail if target is mips(32) softfloat. Result is: ERROR: python3-3.7.2-r0 do_package_qa: QA Issue: non -staticdev package contains static .a library: python3-misc path '/work/mips32r2-24kc-nf-ithinx-linux-musl/python3/3.7.2-r0/packages-split/python3-misc/usr/lib/python3.7/config-3.7m/libpython3.7m.a' non -staticdev package contains static .a library: python3-misc path '/work/mips32r2-24kc-nf-ithinx-linux-musl/python3/3.7.2-r0/packages-split/python3-misc/usr/lib/python3.7/config-3.7m/libpython3.7m.a' [staticdev] ERROR: python3-3.7.2-r0 do_package_qa: QA run found fatal errors. Please consider fixing them. ERROR: python3-3.7.2-r0 do_package_qa: ERROR: python3-3.7.2-r0 do_package_qa: Function failed: do_package_qa ERROR: Logfile of failure stored in: /home/mschoepf/yocto/sa171-warrior/builddir/tmp/work/mips32r2-24kc-nf-ithinx-linux-musl/python3/3.7.2-r0/temp/log.do_package_qa.5549 ERROR: Task (/home/mschoepf/yocto/sa171s-yocto-main/poky/meta/recipes-devtools/python/python3_3.7.2.bb:do_package_qa) failed with exit code '1' Reason is, that configure.ac tries to guess the OS triplet, but fails on mips softfloat, because it merely looks for existence of __mips_hard_float, but I reckon, __mips_soft_float is an indication for mips architecture as well... This might be an upstream issue, or could also be fixed when triplet -> none is accepted in the recipe, i.e. changing poky/meta/recipes-devtools/python/python3_3.7.2.bb like in the second attachment. Do not know, what further implications that might bring... This is something I discovered migrating to warrior.
Created attachment 4512 [details] Alternative patch for recipe python3_3.7.2.bb
Sorry, I think, first patch is the better approach....
I'm a bit worried that if configure is failing to detect mips correctly, there may be bigger problems. This at the very least needs more investigation on what that configure option controls...
I already upstreamed a version of this patch, it is in review, but I think you are probably right with a nights sleep... autotools should determine OS triplet from config.guess *or* from the variables set in the configure script. In Python, there is C Code included in the configure.ac to get the job done...
Which upstream do you mean? Do you have a link?
cpython. Here is my PR: https://github.com/python/cpython/pull/13196 Here is the issue: https://bugs.python.org/issue36852 Regards
The bug is submitted upstream and they've asked to move the issue to github. We can take a local patch if you can send one now please Mattias.
Matthias do you plan to submit the fix to oe-core soon?
Hi Randy, okay, I attached a patch, I hope, that is somewhat useful. Please help, if the patch does not match qa. It is my first patch to OE, so please bear with me. Regards, Matthias
Created attachment 4519 [details] Backported patch from PR mentioned above Hopefully, this is the right way to approach this...
Nice, thanks Mattias. The patch looks good to me aside from an Upstream-Status: tag that is described: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations:_Upstream-Status We don't typically apply patches directly from bugzilla since the community will not get a chance to review them before the patch is applied to master in that caes. Would you be so kind as to send it to the oe-core list, as explained: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded If you need help, just ask here or on IRC: https://old.yoctoproject.org/tools-resources/community/irc Thanks and we're glad to have you dip your toes into the YoctoProject!
Hi Randy, just submitted the patch. Let's see, what happens
Where did you send the patch? It should go to the oe-core list.
Hi Randy, thanks for the follow up. Turns out, my original mail got lost. Now it is being reviewed...
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=c85b26941675d3380be1f2b0032a44251ede1abb