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 configure.ac. The configure script magic just catches for __mips__hard_float defines, but I guess, __mips__soft_float also indicates a mips architecture. 

Added patch

Matthias, would you be able to convert the patch into a Github PR? There are guidelines available at https://devguide.python.org/pullrequest/

Hi!

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

Thanks and Regards,

Matthias

I'll get back on this

The idea with the extension names is to have different names for different ABIs. See https://wiki.debian.org/Multiarch/Tuples 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.

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 configure.ac 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... 

Regards,
   Matthias

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.

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!

I had an issue with yocto warrior and zeus branch for target simulation Qemu_x86. 
I did a report http://bugzilla.yoctoproject.org/show_bug.cgi?id=13842

Thank you to let me know what you think about It.

messages: + msg364940

type: compile error

messages: + msg341900

stage: patch review