For platforms that use configure, the SVN code automatically chooses x64 or x86 based on the system being used to build it.

If only, I'm 64bit cpu & win 7 and it's compiling the x86 recompiler.

Well the recompiler has to match the target. If it's compiling as a 32-bit app it uses the x86 recompiler, if it's compiling a 64-bit app it uses the x64 recompiler. You can't build it as a 32-bit app with the x64 recompiler because that just won't work.
Which compiler are you actually using?

>You can't build it as a 32-bit app with the x64 recompiler because that just won't work.

No kidding, hence the thread about building for x64.

>Which compiler are you actually using?

GCC in mingw.

AFAIK you need mingw-w64 to make 64-bit builds, the original mingw project only supports 32-bit windows.

There's 64bit mingw: https://sourceforge.net/projects/mingw-w64/ and 64bit msys: https://sourceforge.net/projects/msys2/
but no joy in compiling, doesn't even get past autogen before crapping out, hence asking about anyone having already worked out the process to successfully compile. With x64 recompiler being included I'd imagine someone already has the build environment worked out to get it compiled, but just grabbing and installing 64 bit mingw and msys doesn't do it.

Yes, I did. I use MSYS2/mingw-w64 and it built 64-bit native WIN64 version right out of SVN. I can't get it why this was not the same for you. Download from msys2.org is all you need.

Same result with installer from msys2.org, paths aren't automatically configured correctly, stops from not finding the autogen tools and I'd imagine everything else. You used the mingw installer from the url I posted? All I've done was run the mingw and msys2 installers to get where I'm at, did you take any other steps for mingw & msys to see each other? 64bit compile process definitely needs to be added to the build wiki.

How did you install the installer from msys2.org?

Using mingw-w64 w/MSYS 2 is really no different than mingw w/MSYS main difference nowadays is that msys win32 tools are so outdated that you have to compile the latest ver or download them otherwise you'll run into issues when compiling DOSBox. You are better off using mingw or mingw-w64 on Linux and skip MSYS and MSYS2 since there are always issues you'll encounter with them.

I don't recommend using MSYS or MSYS2, use Linux or WSL but if you must the following will provide you with a mingw-w64 w/ MSYS2 environment that will allow you to compile DOSBox for XP+. The version of mingw-w64 provided by the msys2 repo generates binaries that require posix (so XP+) unlike the mingw-w64 provided by Linux repos which don’t.

The official ver of DOSBox iz compiled on Linux so best to stick with what the devs use.

1MSYS2
2http://www.msys2.org/
3msys2-i686-20161025.exe (32bit) (Only use this if you are on a 32bit OS)
4or
5msys2-x86_64-20161025.exe (64bit)
6
7INSTALL MSYS2
8
91. Install MSYS2
10
112. 
1232bit MSYS2 ONLY
13Run rebase: C:\msys32\autorebase.bat
14Run MSYS2 C:\msys32\msys2_shell.cmd
15
1664bit
17Run MSYS2 C:\msys64\msys2_shell.cmd
18
193. UPDATE MSYS2
20Run "pacman -Syu"
21*You may receive error messages about catgets and libcatgets. Remove them.
22Close MSYS2 when prompted. May have to end the "terminal" process in Task Manager.
23Run MSYS2 C:\msysxx\msys2_shell.cmd
24Run "pacman --noconfirm -Syu"
25Exit MSYS2
26
274. Backup the c:\MSYSXX directory
28
29UPDATE AND INSTALL THE TOOLS
30
311. Open C:\msysxx\msys2_shell.cmd
32
332. Run the following command in MSYS2:
34
35"pacman -S --needed --noconfirm {libtool,pkg-config,automake-wrapper,autoconf,make,git,svn,mercurial,tar,gdb,patch,libiconv}"
36
373.  INSTALL MINGW-W64
38** Launch C:\msysxx\mingw32.exe to install and use 32BIT MINGW
39** Launch C:\msysxx\mingw64.exe to install and use 64bit MINGW
40
411.
42Run pacman -S --needed --noconfirm {mingw-w64-i686-clang,mingw-w64-x86_64-clang}
43This should get you the latest gcc as well last time I installed it did.
44
45
46VERIFICATION
47Open mingw32.exe or mingw64.exe and type in "g++ -v" and "clang++ -v", if setup properly then the command should work. If not then you did something wrong.

The type of shell from mintty decides the code generation. MSYS2 for POSIX (linked with msys-2.0.dll), Mingw-w64 32-bit for native WIN32 code and Mingw-w64 64 bit for native code 64 bit. POSIX packages do not prefix with mingw-w64-{i686,x86_64}. DosFreak's instruction may work, but it is overly complicated. There is no need to switch shell type to install the packages. You can install any packages from any of the code generation in any shell type, so I would just recommend you start with Mingw-w64 64 bit shell to install all the necessary packages to build native WIN64 DOSBox.

You should get a nice GUI prompt for shell type running mintty.

DosFreak wrote on 2020-08-18, 03:46:

I don't recommend using MSYS or MSYS2, use Linux or WSL but if you must the following will provide you with a mingw-w64 w/ MSYS2 environment that will allow you to compile DOSBox for XP+. The version of mingw-w64 provided by the msys2 repo requires posix (so XP+) unlike the mingw-w64 provided by Linux repos which don’t.

That wasn't quite true. My DOSBox built with MSYS2/mingw-w64 does not require POSIX. It is linked with msvcrt and DLLs from mingw-w64 DLLs (lib*.dll) and all of them are native WIN64. WSL on Windows 10 does not generate native WIN64 code, which is quite different from using MSYS2/mingw-w64.

MSYS2/Mingw-w64 native codes *officially* do not support XP because current winpthreads requires Windows 7 level of Windows APIs. This can be fixed by downgrading the package or explicitly, statically linked with the older version of winpthreads before it started switching to newer Windows APIs. However, it is unknown if other libraries would break by doing this, so consider this an unsupported hack.

kjliew wrote on 2020-08-18, 03:37:

How did you install the installer from msys2.org?

Eh? There's just running the installer as far as I know. I've uninstalled both and reinstalled msys2 so far, following the steps from msys2.org,
running msys2-x86_64-20200720.exe, select and install to path, run msys2 now, pacman -Syu, close and restart, pacman -Su. Contrary to mys2 org's claim of mission accomplished, no, this doesn't produce a finished build environment.
dosfreaks' install steps roughly the same(ps why step 4, backup msysxxx on a fresh install?,) do dosfreaks' update step pacman -S --needed --noconfirm {libtool,pkg-config,automake-wrapper,autoconf,make,git,svn,mercurial,tar,gdb,patch,libiconv} okie-doke, done.
If you try to build dosbox here, autoconf now successfully runs, but configure will stop from missing the compiler, where mingw comes into play.
Do dosfreaks' mingw install step(takes awhile): pacman -S --needed --noconfirm {mingw-w64-i686-clang,mingw-w64-x86_64-clang}
finally finishes installing, try to rerun configure and.. crash. after repeatedly trying to force kill the locked up msys process(it refused to die) it finally does.
restart mys console, and try configuring again, compiler found, past that point, but configure doesn't complete, no sdl.
try installing with pacman, pacman -S --needed sdl, not found, pacman -S --needed SDL, not found
okay, lets build sdl, tar xvf SDL-1.2.15.tar.gz, autogen, configure, make install, no reported errors
try dosbox configure again, and.. completes.
make.. fingers crossed.. dosbox.exe
does it run? yes.
using x64 recompiler? hmm, how to tell, I don't know a simple check other than to add a log in one of the x64 recompiler functions, so.. LOG_MSG("x64 gen_call_function");
using x64 recompler? yes!
faster? yes! 6-15% going by various benchmarks.
Now a part of the dosbox x64 master race! kjliew and DosFreak thanked profusely at the acceptance speech, jmarsh too.

I think you got most of the stuffs right. MSYS2 is very simple and straight forward and similar to typical Linux build tools and environment, especially if you are also a fan of ArchLinux/pacman.
1. You will need MSYS2 POSIX tools for running standard autogen.sh, configure scripts and GNU make.

1$ pacman -Su --needed autoconf automake autogen awk bison flex make m4

2. You will need WIN64 native code compilers and binutils

1$ pacman -Su --needed mingw-w64-x86_64-{gcc,binutils,libtool,pkg-config}

3. Finally, get the neccessary libraries for DOSBox

1$ pacman -Su --needed mingw-w64-x86_64-{SDL,SDL_net,libpng}

Notice that you need to prefix "mingw-w64-x86_64" for the packages for native code. Some packages (such as gcc, binutils etc) are available in all 3 flavors. You *DO NOT need to build SDL from source. You should refrain from building from source if you can get same stuffs from pacman packaging ecosystem to prevent breakage from a nice and sane build environment. If you do not know what you are doing, then you could potentially have native codes tainted by POSIX libraries and this is a NO-NO.

kjliew wrote on 2020-08-18, 13:58:

You *DO NOT need to build SDL from source.

That might depend which version of SDL is provided? There was a bug that would cause an invalid memory access, and due to it happening inside a window procedure the "application compatibility wizard" or whatever it's called would pop up and say "This program's busted so I'm going to babysit it for you" and then it would just eat any future bad memory references. Undoing it required manually editing the registry to unflag DOSBox as a badly behaving app.

DOSBox SVN only needs SDL1.2 and I think that has been stable for some time and no longer being actively developed. The version provided is the last stable version, I believe, and I never had any issue with that.