I’ve updated the RetroArch redists with libwinpthread-1.dll. MinGW-w64 toolchains come in two flavours, Win32 threads and POSIX threads. Only the POSIX threads variant supports C++11 threads, and it requires libwinpthread-1.dll. Something that pops up from time to time is errors with this lib.
I’ll look at posting an updated toolchain.
Hi Maister,
We 've got an issue when exiting form mame2013 (at least on win64), Retroarch app crash @exit First i was thinking it was an issue with the win osd code ( thread or libco ). But i realise that it didn’t crash if i use an old Retroarch release like the one on official page : http://www.libretro.com/pages/platforms/windows.html
My own build with your last toolchain crash @exit like the one i get in the post about your new game Dinothawr (very cool game anyway).
So now i’m not not sure if it was an core or Retroarch or MinGW-w64 issue. i’ve put a backtrace on the github issue so if you have time to take a look it here : https://github.com/libretro/mame2013-libretro/issues/4 and if have you an idea about this .
Ok forget the message above ;( regarding the BT , i thinks it’s a core issue when exiting related to sound audio_convert_s16_to_float_SSE2 . I try to patch to not update sound if exit state is on , seems to works for me , now i’m waiting more user test and report .
I can confirm the MAME crash on exit issue, I was starting to wonder if it was just my 2 pc’s that I run RA on or if no one else was using the RA port of MAME for Win 7 x64.
Though my experience was a little different, if I compiled MAME using Maister’s gcc 4.8.0 or 4.8.1 toolchain, I would get a crash just starting MAME, but if I used my own gcc 4.7.3 toolchain to build my own Win 7 x64 compile then I would get the crash on exit, so thank you 7rtype, as your patch does seem to fix the issue, at least with my gcc 4.7.3 compiles.
One other thing, Picodrive would not compile with Maister’s gcc 4.8.0 nor 4.8.1 toolchains, but would with my gcc 4.7.3 toolchain and seems to run great.
Seems the prepackaged toolchain provided here should be avoided then until all these issues are resolved.
http://emulation-general.wikia.com/wiki … _RetroArch
Here’s a more up to date guide for building on Windows.
Hi, just wondering if i can get a little help im using the latest zip in this thread. I can compile retroarch just fine, but can’t figure out how to compile any cores or retroarch-phoenix i just end up with errors while building them. Am i missing something?
@Dan9550 What errors are you getting (pastebin them if they’re long). Cores should be pretty painless to build, for the most part.
Hey Maister, could you add mman-win32 to the bundle? Desmume depends on it.
Source: https://code.google.com/p/mman-win32/ Precompiled (i’m using these, extract in x86_64-w64-mingw32): http://sourceforge.net/projects/gtk-min … man-win32/
JIT build doesn’t compile yet so you have to pass DESMUME_JIT=0 just to make sure.
I am using an Intel-based x64 Windows 8.1 computer, but I cannot build the following cores, even while following the instructions from Emulation General:
[ul]
[li]dinothawr[/
2svhc67j][/li][li]handy[/2svhc67j][/li][li]higan mercury[/2svhc67j][/li][li]mame[/2svhc67j][/li][li]mednafen lynx[/2svhc67j][/li][li]mednafen ngp[/2svhc67j][/li][li]mednafen pce fast[/2svhc67j][/li][li]mednafen pcfx[/2svhc67j][/li][li]mednafen vb[/2svhc67j][/li][li]mednafen wonderswan[/2svhc67j][/li][li]nestopia[/2svhc67j][/li][li]puae[/2svhc67j][/li][li]retroarch itrelf[/*2svhc67j][/ul][/li]
What additional information should I tell you?
Are you using the libretro-super script?
Either way, the version of gcc that ships with this environment isn’t new enough to build bsnes-mercury (or the mainline from gitorious) or Dinothawr. It also doesn’t come with python, which is needed for some of the mame cores.
For RetroArch itself, you’re probably missing the libs and headers…?
Pce_fast has changed recently from pce-fast to:
make core=pce_fast -j4
For Mame/Mess I do:
make -f Makefile.libretro "TARGET=mess" PTR64=1 PYTHON="C:/Progra~1/Python/pythonw.exe" -j4
The capital letters do matter. You can change mess to mame or ume. Python path is up to you.
I got this problem when trying to build Retroarch with MinGW for win64:
CC input/drivers_keyboard/keyboard_event_win32.c
CC gfx/common/win32_common.c
CC frontend/drivers/platform_win32.c
LD retroarch.exe
obj-w32/libretro-common/string/string_list.o:string_list.c:(.text+0x38f): undefi
ned reference to `strtok_r'
obj-w32/libretro-common/string/string_list.o:string_list.c:(.text+0x3f1): undefi
ned reference to `strtok_r'
f:/mingw/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-
mingw32/bin/ld.exe: obj-w32/libretro-common/string/string_list.o: bad reloc addr
ess 0x20 in section `.text.unlikely'
collect2.exe: error: ld returned 1 exit status
Makefile.win:147: recipe for target 'retroarch.exe' failed
make: *** [retroarch.exe] Error 1
It’s been a month I’m getting different errors (last build I made is dated 18/08) so I was wondering if this could be a compiler problem.
Are the MinGW-win64 package and headers/libs from this page still up to date?
No, this toolchain is way out of date. I had forgotten about this thread, actually. I should probably unsticky and lock it…
instead, use this guide to get a proper, update-able buildchain: https://gist.github.com/heuripedes/b6da0fea68b648bdd2ae
Thanks, gonna try that.
Of course got some issues. 
I posted at the end of the page. Guess some repositories change their address or something…?
Try do a pacman -Sy first.
$ pacman -Sy
:: Synchronizing package databases...
mingw32 is up to date
mingw64 is up to date
msys is up to date
And then same error.
I used pacman -S --noconfirm --needed pkgconf and dropped the nvidia cg files taken from the old headers/lib archives.
1/ If I start the compilation with:
./configure --enable-glui --enable-xmb make -j4
I end up with a 10MB retroarch.exe that isn’t working…
2/ If in Retroarch-master folder I throw the old headers/lib archives content, then start the compilation with:
make -f Makefile.win -j4
I get a working retroarch.exe, but without libxml2/SDL2/python support and I noticed it crashes after I take a screenshot.
Well, I can see the exe from the buildbot has everything working and uses an older MinGW. Could this environment be shared? which command starts the compilation there?
The buildbot cross compiles from Linux so a copy of that toolchain wont help you. It also uses libretro-super to build everything and you should use it too.
Someone mentioned the msys2 repo was unreliable so Install the missing packages with ‘pacman -U’ from here and try again.