crosscompile-mingw-tedious Dependency: GMP

[minipc]

Following the tedious steps to cross-compile on a Windows8.1 64 hosted Ubuntu 19.04 amd64 VMware Workstation 15 Player virtual machine, I have run into a problem with the GMP dependency compilation, both 32bit and 64bit, lines 3613 - 3635.

The 32bit configure statement, lines 3618-3621 terminates as follows checking for build system executable suffix... configure: error: Cannot determine executable suffix and the make statement, line 3622, generates the following error

make[2]: Entering directory '/home/user/mpv-build-deps/gmp-6.1.2/gmp-build/i686/mpn'
  CC       fib_table.lo
cc1: error: CPU you selected does not support x86-64 instruction set
make[2]: *** [Makefile:492: fib_table.lo] Error 1

The filepaths on lines 3629 and 3631 of the 64bit instructions both produce No such file or directory errors.

I can see how to fix the filepath errors. But I am too new to cross-compilation to be sure how to fix the former issues, though my guess would be that there's something wrong with the 32bit -L, --prefix and possibly --build declarations.

[qyot27]

What CPU is this? I remember that when I was using a Silvermont (Atom Z3735F/Bay Trail-T), occasionally autotools would screw up the build/host triplet(s) and do all sorts of strange things that didn't make any sense. Stuff like telling me that the CPU wasn't 64-bit even though I was doing the compiles in a 64-bit Ubuntu environment, or silently falling back to a native Linux toolchain which would build one part of the dependency 'successfully', and then fail when that first part had to be used to build any subsequent parts. This thankfully was either fixed in upstream autotools or the newer Celeron J3455 I moved to almost a year ago is just simply handled better by the detection routines.

Yeah, those filepaths to the amd64 section somehow slipped through the cracks (cd ../amd64 and ../../configure, respectively, just like most of the other pieces' 64-bit instructions).

That said, of course, I'm pretty sure that the cross toolchain's copy of GMP being discussed here is actually just an artifact of when I still had GnuTLS in the guide, and can be ignored/skipped¹. mbedTLS took GnuTLS' place a while back and it doesn't need GMP.

¹FFmpeg only uses GMP to enable Windows' SChannel native TLS layer (and maybe some rtmpe stuff which uses the TLS stuff too), which the guide avoids because the last time I really tried it, there were lots of issues trying to get it to play nice with youtube-dl. GnuTLS also depended on GMP, and GnuTLS was the only way to get the TLS stuff to still work on XP (short of maybe relying on OpenSSL/LibreSSL, but the guide deliberately doesn't cover non-free components), when XP support was still a concern. When FFmpeg dropped support for XP, I moved the guide away from GnuTLS, and then when I encountered the issues with SChannel interacting with youtube-dl (and realized mbedTLS == PolarSSL, which was my preferred library backend for librtmp/rtmpdump when that was still a thing), moved it to mbedTLS.

[minipc]

Thanks for such a detailed reply. The VMware host machine is a Samsung ATIV9Lite with a proprietary Samsung quad-core processor that CPU-Z reports as an AMD A4/A6 Kabini. So I don't know what the detection routines might make of that. Is there anyway to trick the build process into thinking the CPU selected does support the x86-64 instruction set?

By the way, is librtmp/rtmpdump no longer a thing? Back in the day, I compiled my own customized version, linking PolarSSL. My purpose for wanting to understand your cross-compiler toolchain setup was to perhaps compile a more up-to-date version with mbedTLS.

[qyot27]

Aside from two commits at the end of March, there hasn't been any development on rtmpdump since December 2015, barring any forks that might be floating around out there. Which I assume is because most of the streaming sites that used to use the RTMP(S|E) protocol have long since switched to either DASH or HLS (or added options for those protocols alongside keeping the RTMP lower-quality/resolution streams). Even at that, the last PolarSSL-related commit to rtmpdump was in 2012, concerning fixing compatibility for the then-current 1.2 series. Adding mbedTLS support to rtmpdump would probably require extensively digging and refactoring the PolarSSL module, if the skeleton of the PolarSSL stuff could still be used at all.

FFmpeg doesn't require librtmp to support RTMP, though; it has its own native implementation, and generally then relies on the linked TLS library to support the encrypted form. The documentation is not altogether clear about where any gaps might be, but with use of RTMP itself rapidly declining, I think I might have simply made peace with the idea that if FFmpeg can't support it when linked against mbedTLS, then I shouldn't worry about it.

Using just mbedTLS inside FFmpeg, this is the output of ffmpeg -protocols list:

ffmpeg version r93433+7 master-4d8875ec23 HEAD-4f45f01374
 contains: avs_newheader datetime new_pkgconfig silent_invoke versioninfo
 Copyright (c) 2000-2019 the FFmpeg developers
  built on Mar 21 2019 16:37:30 with gcc 8.3.0 (GCC)
  libavutil      56. 26.100 / 56. 26.100
  libavcodec     58. 47.105 / 58. 47.105
  libavformat    58. 26.101 / 58. 26.101
  libavdevice    58.  7.100 / 58.  7.100
  libavfilter     7. 48.100 /  7. 48.100
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale      5.  4.100 /  5.  4.100
  libswresample   3.  4.100 /  3.  4.100
  libpostproc    55.  4.100 / 55.  4.100
Supported file protocols:
Input:
  async
  bluray
  cache
  concat
  crypto
  data
  ffrtmpcrypt
  ffrtmphttp
  file
  ftp
  gopher
  hls
  http
  httpproxy
  https
  mmsh
  mmst
  pipe
  rtmp
  rtmpe
  rtmps
  rtmpt
  rtmpte
  rtmpts
  rtp
  srtp
  subfile
  tcp
  tls
  udp
  udplite
Output:
  crypto
  ffrtmpcrypt
  ffrtmphttp
  file
  ftp
  gopher
  http
  httpproxy
  https
  icecast
  md5
  pipe
  prompeg
  rtmp
  rtmpe
  rtmps
  rtmpt
  rtmpte
  rtmpts
  rtp
  srtp
  tee
  tcp
  tls
  udp
  udplite

All the RTMP protocols are listed, for both input and output. And this was without using librtmp at all.

[minipc]

Thank you for the crash rtmp update. Either I've unwittingly been living under a rock, or the ball I thought I was keeping my eye on belonged to another sport. Either way, I'm now completely woke to the streaming situation. I would still like to follow through on the cross-compilation exercise though. You never know when it might turn out to be useful. Any further thoughts you might have on the compile error would be very well received.

[qyot27]

Since I'd just fresh installed 19.04 a couple days ago, I was initially going to wait until GCC 9.1 gets released at either the end of this month or early May (projected). But as I still had the .deb for 8.3 lying around, I checked the GMP step myself, and confirmed that it still throws that error on my setup as well.

The solution, as it turns out, was staring me in the face: when the configure step is complete, the report that it spits out shows that it's trying to use the 64-bit ABI even when building as 32-bit. A quick check of ./configure --help shows that it recognizes the ABI environment variable, so all it took to get 32-bit builds working was to pass ABI=32 to configure as an on-demand environment variable. The guide has been minorly updated to reflect this (as well as to fix the path issue on 64-bit, add a note about what GMP does, and to add the checkinstall steps that were missing).

[minipc]

thanks. unfortunately it's taken a few days for me to return to this problem, as the gmplib.org site seems to have been offline, and i had foolishly started over with a fresh virtual machine, in case any of my own attempts to fix the issue had made things worse. so i'd lost my previous working environment and downloads. and now that the site's back up, i've not progressed much, as for me, even the amended recipe fails at the configure step with the same Cannot determine executable suffix error. maybe i just don't have a suitable host processor on which to cross compile?

[qyot27]

That particular error seems to be very idiosyncratic to GMP - it only shows GMP-related results when searching for it on Google. Inside of the results, two different things jumped out at me:

A) It might conflict with the presence of Wine and wine-binfmt (I skipped this step in the guide prep when I tested it with the copy of GCC 8.3.0 I had lying around).

B) It might involve the GMP_PROG_EXEEXT_FOR_BUILD variable being used automatically when it shouldn't be used at all, or vice versa.

The possibility of Wine tripping it up brings us back around to how the CPU is being detected. While the processor in the laptop itself is an AMD Kabini, it could in fact be VMWare interfering somehow with the processor detection (I wouldn't know; I use VirtualBox - or even QEMU - whenever I need a VM). Generally, this is why both --build and --host get passed to configure for some of the pieces in the guide, and it's sometimes enough to just force-override the --build to what you know is appropriate. You could even try removing the --build option and leaving it to just use --host (it still might not work, but it'd remove that as a possible problem).

If you copy-pasted the instructions as-is, it was attempting to force --build=x86_64-pc-linux-gnu, which seems redundant if you're running on an amd64 Linux distro, but sometimes processors get misdetected (like the Silvermont I used to use did). You could try --build=x86_64-w64-mingw32 to attempt to force it to think it's being compiled on a Windows machine for a Windows machine, but that will require Wine and wine-binfmt to be present.

[qyot27]

Okay, managed to test again and reproduce the error. It is a conflict with Wine and wine-binfmt. The solution is to force --build and --host to x86_64-w64-mingw32.