Not supported on m68k, riscv

[James Cowgill]

The above architectures are not supported by the configure script. It would be good to add them. Their "uname -m" names are "m68k", "riscv32" and "riscv64".

Having said that, is it a good idea to fallback to a "generic" architecture if cpu detection fails? I don't see why mplayer needs to care about the cpu architecture if it's not going to do any optimization on it anyway.

[reimar]

Without optimization, MPlayer is likely to be unusable anyway, thus there is little value in it being able to build.
On the other hand, falling back to generic (without the user indicating they really want to have a likely-unusable build) means a bug in the autodetection results in broken binaries instead of a configure failure.
Or in short:
falling back to "generic" is a horrible idea because configure should not silently create broken binaries, and that is far more important than building on unusual architectures.

[reimar]

It would be of great value if there are easy ways to test these architectures btw (easily usable qemu images, qemu-user support, crosscompile toolchains in Debian...), before we try to "officially" support them.
And a even better first step would be to get them added to the FFmpeg test infrastructure: ​http://fate.ffmpeg.org/?sort=arch

[beastd]

Hmm. Not sure what the best option is here...

Reimar already gave some pointers.

What is your use case? Is it building for packaging?

If it is, I think you could conditionally specify generic just for those architectures. That is if you think it will not baffle the ones installing that package.

[James Cowgill]

This is for the Debian packaging. I've already applied a patch to fallback to the "generic" architecture if the cpu detection fails. The reason for this is because I know it will work in the future if a new architecture is later added to Debian. What you suggest would work but it's annoying having to update the package repeatedly. As far as the fear of producing broken binaries goes, I can't see how the current code will fail on any of the popular architectures, so I think what I've done is fine. As a comparison, FFmpeg prints a warning when building with an unknown architecture, but carries on regardless.

I believe m68k and riscv64 already have cross toolchains in Debian, support in QEMU etc. Probably there are some images available, but I don't have any links at the moment.

[beastd]

Replying to jcowgill:

This is for the Debian packaging. I've already applied a patch to fallback to the "generic" architecture if the cpu detection fails. The reason for this is because I know it will work in the future if a new architecture is later added to Debian. What you suggest would work but it's annoying having to update the package repeatedly. As far as the fear of producing broken binaries goes, I can't see how the current code will fail on any of the popular architectures, so I think what I've done is fine. As a comparison, FFmpeg prints a warning when building with an unknown architecture, but carries on regardless.

Your patch that gets applied when building the Debian package seems partially wrong in regard to the surrounding code. You never set the variable host_arch to UNKNOWN which effectively disables the conditional second call to set_host_arch with "uname -p" as input.

I have no strong opinion regarding this issue. If Reimar is OK with the fallback to generic and appending a warning to the configure output, I would volunteer to implement that.

[...]

[reimar]

TL;DR: I guess my best proposal is to add an option enabling that behaviour, for distributions strongly favouring low effort and fast turn-around on architecture support.

As to generating broken binaries on popular architectures there are two cases that can cause issues:
1) uname changes its output
2) a typo when --target is used
The former might be unlikely, but it has happened before (also, unpopular architectures still matter).
At least the latter needs some protection in whatever the solution is in the end, and a message is really not enough (we print far too much stuff for anyone to notice that).

The other issue is that generic is intented for one-shot experiments and initial porting effort. Due to not setting even essentials like unaligned access and fast 64 bit support flags correctly, it flushes performance down the drain to save a few minutes of porting effort.
The question is essentially: do we want a crapshot "port" with users running needlessly slow code for decades, worst case long into when the architecture became somewhat popular or do we want to somewhat force people to actually spend a minimum amount of time to set up some basics?
It's a question of priorties: Is it better to easily and quickly be able to provide "something" really crappy and entirely untested to users or to enforce a minimal porting and testing effort first? Ok, the "untested" part is kind of independent, so that's an unfair exaggeration, but you get the idea!

If the former is more in line with Debian considering the many supported architectures, I don't really mind some --allow-unsupported-architecture option for example.
I feel for people building from source manually I'd rather have them forced to consider this themselves though. Maybe the message needs to be reviewed to ensure it is actually helpful though, pointing e.g. at the --target=generic option and alternatively the code and basic options to set up for better support.