Author Topic: EXPERIMENTAL native host system sound device output for OpenMPT on Wine on Linux  (Read 2381 times)

Offline manx

  • OpenMPT Developers
  • *****
  • Posts: 136
https://pastebin.com/dpprgJTy
Can you please allow to build 32bit wrapper on 64bit system (-m32 or something)?

Theoretically possible, but certainly will not happen to be supported in the near future.

There is a hidden setting [WineSupport]ForeignOpenMPT. If you set that to 1, OpenMPT will try to build for non-native bitness, however that feature is unsupported and not very well tested and I cannot remember right now if it even ever worked even on Debian systems where I test mostly.


We do explicitly not provide active support for this situation though, because of various reasons:

The amount of differences between distributions in the way compiling for Wine is already amazingly huge as it is, even when only targeting the native platform. Targeting foreign bitness will increase the amount of situations to support manyfold.

Library placement in the file system differs completely between Debian, Ubuntu, other Linux, other platforms (i.e. at least 4 ways to handle it). Some systems completely special case Wine and do not allow to even install general 32bit packages on 64bit systems at all. This implies having to consider which packages are even available there at all. Detecting available foreign packages is also not really portable (yes, pkg-config, but we would have to GUESS the actual host triplet and pkg-config path used for 32bit) (also, this would not be any easier when building by hand).

So no, this is an experimental feature, and only supports a subset of available configurations. You either have to use native bitness OpenMPT (and are thus limited to 64bit VST plugins due to the Wine UI rendering problem, though we might be able to provide a work-around for that sometime, albeit not soonish either), or use 32bit OpenMPT on your 64bit system and not use the Wine integration feature (WASAPI support in Wine and OpenMPT works nearly perfect these days, so you would not lose all that much anyway).

In any case, this is and will stay to be a highly experimental feature because it requires an unproportionally huge amount of development time to implement and test (the test matrix is incredibly huge, compared to other features), and I do not want to invest the time to extend the scope that much for ever so smaller diminishing returns.


We might support building by hand some time, but not right now.