generate 64-bit DLLs (and update gcc for it to work)

[dgruss]

With this change we hopefully switch to x64_64 and do not need the old 32-bit dlls anymore. Therefore:

• replaced 32bit constants with 64bit equivalents everywhere
• on my system exporting PATH again was necessary, can remove if it is wrong for other systems
• ramped up from -j2 to -j8 for faster builds
• remaining changes and gcc update to 13.3 for things to even just compile

[s09bQ5]

The 32 bit build contains some patches to force the DLLs to specific non-overlapping virtual address regions (linker parameter --image-base and --disable-dynamicbase) to ease debugging. Did you check if the chosen addresses still work?

[dgruss]

The 32 bit build contains some patches to force the DLLs to specific non-overlapping virtual address regions (linker parameter --image-base and --disable-dynamicbase) to ease debugging. Did you check if the chosen addresses still work?

i have only seen that in some ffmpeg patch, not anywhere else?
also: 64-bit virtual addresses (48-bit actually) look quite different than 32-bit virtual addresses and we shouldn't place things at the same location. lastly, by doing that we circumvent the ASLR security feature that is enabled by default on all modern OSes. maybe we shouldn't do that anyways.

[dgruss]

changed it and the local compile worked fine

[dgruss]

@s09bQ5 i basically only need to adjust the urls and then it could be merged, right? that would allow to proceed in the USDX repo then

[dgruss]

it is a bit of a chicken-egg problem.

this PR needs the 64-bit PR's code, but the USDX 64-bit PR needs the build artifacts / release zip from this PR.

So, we could/should maybe:

1. merge this PR with the URL pointing to the 64-bit branch as is, then it will build working artifacts
2. merge the 64-bit PR in the USDX repo with this repo's mxe release url
3. update this repo again with the USDX master branch URL, building new working artifacts
4. rebuild the USDX repo with the new dlls

[s09bQ5]

To solve that chicken-egg-problem, I suggest you make a separate PR in USDX for your changes to the projectM wrapper and the OpenCV wrapper def file.
Once that has been merged, you can use that commit to fetch the wrapper sources here.

[dgruss]

Not sure I need the opencvwrapper.def file in there - mxe does not pull that from the USDX repo

[s09bQ5]

Actually, you are right. The def file is needed only to generate a static library that contains the import section for code that wants to use the dll. But Free Pascal creates the import section from the function declaration.

[dgruss]

tested it, the mxe part works, the game runs without issues. as soon as this is merged i will adjust the x64 PR in the other repo

[dgruss]

all discussed changes implemented, tested it again, works still fine

[dgruss]

tested the CI built dlls locally and they work (all but libopencv_core460.dll are byte-identical to my local build, and that one just has a few bytes of difference)

[dgruss]

should i make a force push to make it 1 commit? or do you want to squash it?

x86_64 wrapper DLL build for USDX dependencies


Extend the MXE-based Windows dependency build to produce the x86_64 DLL
set needed by 64-bit USDX, including the OpenCV and projectM wrapper
DLLs.

Update build.sh to target x86_64, fetch the USDX wrapper sources from
the USDX repository, build the new wrapper packages, and collect the
resulting DLL bundle in the format expected by USDX.

Refresh the surrounding toolchain and package setup:
- update GCC to 13.4.0 and adjust the MinGW header layout patching
- force DWARF-friendly settings for the x86_64 build where needed
- trim OpenCV to the smaller feature set required by the wrapper and add
  an MXE package for the USDX OpenCV wrapper
- add MXE packaging and MinGW compatibility fixes for projectM,
  including autoreconf-based build fixes used on other platforms
  and the USDX projectM C wrapper

This prepares the MXE repo for the upcoming USDX Windows x86_64
builds.

or so?

[s09bQ5]

Make a force push so that we get that nice commit message

[dgruss]

done

[barbeque-squared]

@s09bQ5 am I correct that this and UltraStar-Deluxe/USDX#1149 are essentially done at this point, the only thing remaining being (in sequence):

• merge this mxe PR
• make a mxe pre-release
• have the USDX PR updated (it's probably just restoring the dll download script
• merge the USDX PR

Ideally this can be part of the next release.

[dgruss]

the USDX PR is already updated

[s09bQ5]

The USDX PR will probably have to be updated again because the merge in the MXE repo will create a merge commit.

[barbeque-squared]

Yep I know that (it's why the USDX RELEASING.md has a part about "if there is an mxe prerelease, actually release it" etc) but I'll merge the mxe part (= this PR) + make a prerelease later today then.

[dgruss]

Thank you @s09bQ5 for the work on this PR! 🎉