Fixes to libretro makefile for emscripten builds

[JoeOsborn]

Now that we can support threads in emscripten, this Makefile should be modified.

I ran into duplicate symbol problems when compiling PCSX's thread support, so I had to disable threads within the emulator to avoid duplicates of rthread.o. I'd appreciate advice in general on working with cores that could have threading support and including libretro-common under static linking scenarios (since retroarch also includes libretro-common).

[notaz]

"pthread ?= 0" at the top misleadingly suggests it applies to many things when it's really emscripten specific. And there are plenty of confusing variables already...

Also no need for NDRC_THREAD as it only effects dynamic recompiler, which is naturally off for emscripten.

For clashing objects I've started using partial linking, see PARTIAL_LINKING in the main Makefile. No idea if something like that exists for emscripten.

[JoeOsborn]

I agree re: pthread ?= 0, would you prefer that happen in the existing if platform check or in a new if platform check at the top? Putting defaults at the top has some benefits but I can also see an argument for just dropping that into the emscripten block.

For NDRC_THREAD, I actually found that emu_if.c was compiling in some thread stuff even under emscripten if pthread was turned on. So maybe there’s a bug in the preprocessor statements there?

As for partial linking I’m actually not sure what emscripten will do. I’ll give it a try tomorrow.

[JoeOsborn]

I had a chance to look at partial linking after all. I think it could work but the issue isn’t the libretro api, it’s the libretro-common stuff like rthread.o (and I think wasmld doesn’t use linker scripts: emscripten-core/emscripten#23637 (comment) ).

I suspect an additional branch in the makefile (partial linking and emscripten) would call wasm-ld with default hidden visibility, and only make visible the libretro api symbols? Or, some LDFLAGS could be used to do that on emscripten in all emscripten builds.

[notaz]

Unless it affects anything else, please keep it in the emscripten block.

Seems like emu_if.c was just including some unnecessary headers, I've updated it now.

For the threading stuff I'd suggest hacking something up locally and testing it to see if there's any real benefit first (if any of it works at all). All those complications might be just not worth the effort.

[JoeOsborn]

Yeah, I'm working on pthread-enabling all of retroarch on emscripten, so if cores can compile with threads I figured I may as well compile them with threads assuming there's a reason they use threads on native in the first place. I'll do some more investigation.