Title: Python3.7.2 fails to cross-compile (yocto / openembedded) when target is mips softfloat
Type: compile error Stage: patch review
Components: Cross-Build Versions: Python 3.7
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Alex.Willmer, SilentGhost, doko, medhi, mschoepf
Priority: normal Keywords: patch

Created on 2019-05-08 16:01 by mschoepf, last changed 2020-03-24 16:25 by medhi.

File name Uploaded Description Edit
0001-fixing-finding-of-triplet-on-softfloat-mips.patch mschoepf, 2019-05-08 16:01
Pull Requests
URL Status Linked Edit
PR 13196 open python-dev, 2019-05-08 16:43
Messages (9)
msg341894 - (view) Author: Matthias Schoepfer (mschoepf) * Date: 2019-05-08 16:01
Python 3.7.2 fails to cross compile for yocto / openembedded when target is mips softfloat, because the OS triple is not detected correctly by The configure script magic just catches for __mips__hard_float defines, but I guess, __mips__soft_float also indicates a mips architecture. 

Added patch
msg341900 - (view) Author: SilentGhost (SilentGhost) * (Python triager) Date: 2019-05-08 16:10
Matthias, would you be able to convert the patch into a Github PR? There are guidelines available at
msg356239 - (view) Author: Matthias Schoepfer (mschoepf) * Date: 2019-11-08 11:53

I submitted this patch, it even is now on yocto zeus. Any progress, will someone review it?! 

Thanks and Regards,

msg356240 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2019-11-08 11:55
I'll get back on this
msg356300 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2019-11-09 13:10
The idea with the extension names is to have different names for different ABIs. See for the list of ABIs that are "known", or documented.

mips-linux-gnu is documented as MIPS32r2+FPXX, which is a different ABI than MIPS32r2 apparently, and not compatible, so it should have a different name.

Other architectures like arm-linux-gnueabi and arm-linux-gnueabihf have the hard/soft difference encode in their GNU triplet name, and apparently nobody did that for mips.

One solution would be to define a mips-linux-gnusf Multiarch name, which then would be different than the GNU triplet.  Note that there's no "authority" to define the Multiarch names, however in most cases the GNU quadruplet without the vendor is chosen as the MA name.

Other solutions could be to define no MA name, or go with your solution, just ignoring things. I'd still prefer something defining a name for this ABI.
msg356373 - (view) Author: Matthias Schoepfer (mschoepf) * Date: 2019-11-11 17:44
Hi Matthias,

thanks for your comment. I am not sure, if I understand correctly or if it is really the problem here. So, if you take a look at the patch, or at the current version of right now, there is s section:

AC_MSG_CHECKING([for the platform triplet based on compiler characteristics])

There is a handcrafted C Program (well, rather C-Preprocessor), which tries to guess, for what Platform the compiler is used for. The initial problem with my platform is this line:

# elif defined(__mips_hard_float)

The reason beeing, on mips soft float, __mips_hard_float is not defined. But the triplet should be mips-linux-gnu. Otherwise, the build will fail later down the road. 

One could add || defined (__mips_soft_float) to fix this issue. Indeed, that was my first patch. But I was not really satisfied. I think, using a custom C program for finding out the target triplet is generally not the right approach, because, you will always miss an architecture or fail to correctly guess the triplet (my guess). I think, it is much better, to rely on autotools for this. At the end of the day, autotools where made for that purpose, right? 
So I replaced the whole program with AC_CANONICAL_TARGET. It should always do the right thing *and* is Cross-Compiler aware. In the end, the triplet is mips-linux-gnu. It also removes lots of hard to maintain code (seems, like nobody really knows its internals?!). 

My trouble is, that I do not know, what other side effects this might have. On the latest release of yocto, my patch is used, and at least, I am not aware of any problems, but that does not mean, that there are none... 

msg356374 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2019-11-11 18:00
You misunderstand. The GNU triplets are ambiguous. mips 32bit big endian soft float, and mips 32bit big endian hard float are *not* ABI compatible, but map to the same GNU triplet.

The check *is* cross compiler aware, it's run with the target preprocessor/compiler.
msg356381 - (view) Author: Matthias Schoepfer (mschoepf) * Date: 2019-11-11 19:06
Hi Matthias,

thanks for clarification. Maybe I am under a totally wrong impression, but to me is having soft float comparable to not having some special SSE instruction sets with x86. You are missing some instructions, that your code may or may not need, and the compiler replaces them with some other, not hardware accelerated functions. 

To what extend is the handcrafted version better than the one, autotools are providing? 

I really like to learn here. 

Many thanks already!
msg364940 - (view) Author: khoja (medhi) Date: 2020-03-24 16:25
I had an issue with yocto warrior and zeus branch for target simulation Qemu_x86. 
I did a report

Thank you to let me know what you think about It.
Date User Action Args
2020-03-24 16:25:15medhisetversions: - Python 3.8
nosy: + medhi

messages: + msg364940

type: compile error
2019-11-11 19:06:04mschoepfsetmessages: + msg356381
2019-11-11 18:00:07dokosetmessages: + msg356374
2019-11-11 17:44:23mschoepfsetmessages: + msg356373
2019-11-09 13:10:46dokosetmessages: + msg356300
2019-11-08 11:55:53dokosetmessages: + msg356240
2019-11-08 11:53:22mschoepfsetmessages: + msg356239
2019-05-08 17:01:56SilentGhostsetnosy: + doko
2019-05-08 16:43:24python-devsetpull_requests: + pull_request13107
2019-05-08 16:10:23SilentGhostsetversions: + Python 3.8
nosy: + SilentGhost

messages: + msg341900

stage: patch review
2019-05-08 16:01:08mschoepfcreate