Cant compile on latest devkitpro r33

Ntemis commented 5 years ago

I get error: no matching function for call to 'max(long unsigned int, u32&)' in several places in WiiFlow_Lite/source/gui/text.cpp

http://dpaste.com/14HYZ07

Fledge68 commented 5 years ago

yes i know. wiiflow lite is compiled with ppc r30. if compiled with r33 then the plugin for dosboxwii doesn't work correctly. not sure why, but it does work correctly if wiiflow lite is compiled with r30. so i stayed using r30.

Ntemis commented 5 years ago

Is because dosboxwii is in hiatus since 2012 why you want to support this? Doesnt retroarch provide dosbox for wii or something? Edit found it: https://github.com/libretro/dosbox-libretro/blob/master/Makefile.libretro#L137

Wiimpathy commented 5 years ago

DOSbox libretro isn't in the builbot for Wii:http://www.retroarch.com/?page=platforms

DOSBox Wii has been tested for a long time, it's in a known pack that most users download. By the way, all recent Retroarch at least since 1.7.4 had a bug when used as plugins. It was skipping the .cfg file, so it was resetting to default each time you launched a game. It happens due to a devkitPPC update that affects getcwd (and also the way Wiiflow handles the paths?). This is a fix : https://github.com/libretro/RetroArch/commit/b5eedbaed7535e7b365287ee9194f5f9e607065c

@Fledge68 , so if you're also using an older libogc, isn't there a bug related to time?

Ntemis commented 5 years ago

Latest libretro dosbox freshly compiled without any issues on dkp r33 https://www.androidfilehost.com/?fid=11410963190603890390

Fledge68 commented 5 years ago

@Wiimpathy the time bug appears in r31 and r32. wfl is using r30 before the time issue. r33 fixes the time issue but for some reason it effects the controllers of dosboxwii.

Fledge68 commented 5 years ago

@Ntemis i downloaded your file but it gives me .a file. am i supposed to rename it to .dol?

gingerbeardman commented 5 years ago

Seems to be an .a or .ar archive inside a .tar?

here it is extracted and converted to zip, it's a bunch of compiled source files: dosbox_libretro_wii.zip

Fledge68 commented 5 years ago

thanks but that doesn't help me.

Ntemis commented 5 years ago

Here is your answer https://github.com/libretro/dosbox-libretro/blob/master/Makefile.libretro#L138

RetroArch on Wii is statically linked. With statically linked RetroArch, each executable is a separate libretro core instead of the core being separately loaded from a single executable. A pre-existing libretro library needs to be present in the root directory in order to link RetroArch Wii. This file needs to be called 'libretro_wii.a'. So... Copy .a to /dist-cores, run ./dist-cores.sh wii in /dist-cores, get compiled stuff in /pkg/wii/.dol What i mean is drop that into your retroarch source tree and rename to libretro_wii.a and then build libretro to link against it

Wiimpathy commented 5 years ago

Retroarch buildbot is still using DevkitPPC 29.1. That's a good thing.

@Ntemis , you know that there's no virtual keyboard in this core for the Wii. USB keyboard isn't implemented either. Both features are present in Dosbox Wii. You could share a .dol though so that we can actually test it...

Ntemis commented 5 years ago

Please git clone retroarch from: https://github.com/libretro/RetroArch then run ./fetch-submodules.sh unpack my dosbox_wii.a package, and rename it to libretro_wii.a and place it in retroarch/dist-scripts/ then run ./dist-cores.sh wii

done and @Wiimpathy is r27

Wiimpathy commented 5 years ago

@Ntemis You're wrong, It's r29. See this : https://github.com/libretro/RetroArch/commit/0e8c9b8acafdff10aa6061d5d08c8451e320109e Look at this line too : https://github.com/libretro/fbalpha2012_neogeo/blob/master/makefile.libretro#L259 Please share a dol file, uploading static lib isn't very useful.

I've modified Dosbox Wii in 2016 (I don't remember with which libs): https://gbatemp.net/threads/wiiflow-an-open-source-gui-usb-loader.204106/page-800#post-6222637 I wonder if it's also affected by the controller bug...

Fledge68 commented 5 years ago

@Wiimpathy what controller bug?

Wiimpathy commented 5 years ago

The bug you were talking about when launching Dosbox Wii...

Fledge68 commented 5 years ago

@Ntemis can we close this issue?

Ntemis commented 5 years ago

If you have no intention to update to dkp r33 then yes.

Fledge68 commented 5 years ago

if you would do as wiimpathy said - Please share a dol file, uploading static lib isn't very useful. otherwise we can't test it.

gingerbeardman commented 5 years ago

If you have no intention to update to dkp r33 then yes.

@Ntemis please understand we need more help than you seem willing to give.

Ntemis commented 5 years ago

But is very easy to make the .a to dol as i already explained the how to. I cant do it for you as r33 is broken on ra atm and the team(Retroarch) want me to update dkp to r33 on their builbot after i push a fix for ra just to provide you a dol to test. Is easier for you to do it since you have the older dpk than i. Other than this issue, any help you need i can provide. I am part of Lakka distro team so i can talk with ra devs anytime so telling me what is needed to be fixed for the wii port i will try to transfer it to the right hands for the job.

Fledge68 commented 5 years ago

so i cloned retroarch. ran fetch-submodules.sh (took a while to download everything especially assets.) got your file and renamed it libretro_wii.a and placed it in dist_scripts now for the problem. i'm on windows 10. in the folder dist_scripts i hold shift and right click to open windows powershell (cmd prompt) then i type ./dist-scripts.sh wii and hit enter a small window quickly pops up and then closes before i have a chance to read anything. no dol file is made in pkg/wii folder.

WinterMute commented 5 years ago

@Fledge68 I've seen people have issues with powershell & the tools. Can you try it from an msys2 shell & see if it's any more informative?

@Wiimpathy what's the getcwd issue? Would be nice if people reported these things.

Wiimpathy commented 5 years ago

Ok, here's dosbox libretro : https://www.mediafire.com/file/37ivb49c971vg6k/dosbox_libretro_wii.zip/file I've added the 'access' function since it wasn't in the devkit yet.

I'll repeat myself but using this core instead of Dosbox Wii is less convenient:

No USB keyboard/mouse.
No Virtual keyboard.
On which Dosbox version it's based? Performance?

@Ntemis Please, don't force libretro to upgrade the Devkit! Here's why:

There's no Retroarch Wii maintainer anymore.
The Wii has very limited RAM. Compiling with latest libs make the dol bigger. Some cores (FBA & FBA Neogeo) will be too large to load or start some games...
Expect broken cores... Fba neo for example, maybe others... And because of reason #1...
Anything past R29.1 doesn't add anything essential regarding new features.

It's the same for WiiFlow. Why upgrade if there's no real benefit. We still don't know why Dosbox Wii has an issue with WiiFlow an r33. There are about 50 plugins so maybe others are affected. Fledge68 and other devs won't waste their time debugging this kind of stuff. Especially at this stage in Wii homebrew life...

@WinterMute There was an issue when launching Retroarch cores with WiiFlow: https://github.com/libretro/RetroArch/pull/7853 It was working before they update the DevkitPPC to R29.1.

DevkitpPPC R30+ also breaks the Nand Virtual Memory in fbalpha2012_neogeo : https://github.com/Wiimpathy/fbalpha2012_neogeo/blob/Wii_VM/src/burner/libretro/wii_vm.c There's no warnings/errors when compiling. It's just stuck after creating pagefile.sys. Do you have any idea why?

Fledge68 commented 5 years ago

@WinterMute even though wiimpathy managed to compile it (thank you wiimpathy!) i still tried with msys2. msys2 works better but i still got a error. here's the text from msys2:

$ ./dist-cores.sh wii make: Entering directory '/c/sources/retroarch/retroarch' rm -f retroarch-salamander_wii.dol rm -f retroarch-salamander_wii.elf rm -f frontend/frontend_salamander.o frontend/frontend_driver.o frontend/drivers/platform_gx.o frontend/drivers/platform_wii.o frontend/drivers/platform_null.o libretro-common/file/file_path.o libretro-common/hash/rhash.o libretro-common/string/stdstring.o libretro-common/lists/string_list.o libretro-common/lists/dir_list.o libretro-common/streams/file_stream.o libretro-common/vfs/vfs_implementation.o libretro-common/file/retro_dirent.o libretro-common/encodings/encoding_utf.o libretro-common/compat/compat_strl.o libretro-common/compat/compat_strcasestr.o libretro-common/compat/fopen_utf8.o libretro-common/file/config_file.o file_path_str.o verbosity.o wii/app_booter/app_booter.binobj wii/libogc/libfat/cache.o wii/libogc/libfat/directory.o wii/libogc/libfat/disc.o wii/libogc/libfat/fatdir.o wii/libogc/libfat/fatfile.o wii/libogc/libfat/file_allocation_table.o wii/libogc/libfat/filetime.o wii/libogc/libfat/libfat.o wii/libogc/libfat/lock.o wii/libogc/libfat/partition.o make -C wii/app_booter clean make[1]: Entering directory '/c/sources/retroarch/retroarch/wii/app_booter' rm -f app_booter.bin rm -f app_booter.elf rm -f crt0.o main.o ../../libretro-common/crt/string.o make[1]: Leaving directory '/c/sources/retroarch/retroarch/wii/app_booter' make: Leaving directory '/c/sources/retroarch/retroarch' make: Entering directory '/c/sources/retroarch/retroarch' rm -f retroarch_wii.dol rm -f retroarch_wii.elf rm -f griffin/griffin.o wii/app_booter/app_booter.binobj make -C wii/app_booter clean make[1]: Entering directory '/c/sources/retroarch/retroarch/wii/app_booter' rm -f app_booter.bin rm -f app_booter.elf rm -f crt0.o main.o ../../libretro-common/crt/string.o make[1]: Leaving directory '/c/sources/retroarch/retroarch/wii/app_booter' make: Leaving directory '/c/sources/retroarch/retroarch' make: Entering directory '/c/sources/retroarch/retroarch' /opt/devkitpro/devkitPPC/bin/powerpc-eabi-gcc -Wall -std=gnu99 -DGEKKO -DHW_RVL -mrvl -mcpu=750 -meabi -mhard-float -I. -Ilibretro-common/include -Ideps/libz -Iwii/libogc/include -std=gnu99 -DIS_SALAMANDER -DRARCH_CONSOLE -DHAVE_RARCH_EXEC -DGEKKO -Wno-char-subscripts -O3 -c -o frontend/frontend_salamander.o frontend/frontend_salamander.c make: *** [Makefile.wii.salamander:124: frontend/frontend_salamander.o] Error 1 make: Leaving directory '/c/sources/retroarch/retroarch'

Wiimpathy commented 5 years ago

It's a path issue. It doesn't find powerpc-eabi-gcc.exe. Check where devkitPPC is installed and if the environments variables have been set correctly. And forget Ntemis .a file, he doesn't know what he's talking about since he never test! You must re-compile dosbox-libretro yourself first!

WinterMute commented 5 years ago

It's not quite a PATH issue - you need to add /opt/devkitPPC/bin to the path or the tools gcc calls (cc1 for example) can't find the dlls on windows. RA build system is just using full path to call gcc & not adding to PATH.

3po3po commented 4 years ago

Error on r35 devkitpro and libogc18

$ make -f Makefile.wii.salamander /opt/devkitpro/devkitPPC/bin/powerpc-eabi-gcc -Wall -std=gnu99 -DGEKKO -DHW_RVL -mrvl -mcpu=750 -meabi -mhard-float -I. -Ilibretro-common/include -Ilibretro-common/include/compat/zlib -Iwii/libogc/include -std=gnu99 -DIS_SALAMANDER -DRARCH_CONSOLE -DHAVE_RARCH_EXEC -DGEKKO -Wno-char-subscripts -O3 -c -o frontend/frontend_salamander.o frontend/frontend_salamander.c make: *** [Makefile.wii.salamander:124: frontend/frontend_salamander.o] Error 1

Im new to this matter please guide straight and clean thanks

3po3po commented 4 years ago

Hello people i have issues when compiling retroarch for WII i just straight downloaded DEVKITPRO which include MSYS2 and maybe all libraries needed *checked boxes for wii and GC DEV and at end i saw all stuff update pacman etc libogc … somebody explained on GBA temp tthat is best option to leave all default . and followed this mini guide after ./libretro-build-wii.sh i saw that i have only one successful core build fbneo_libretro_wii.a there where 30 fails !!! AND from there i get one BIG MESS

$ ./dist-cores.sh wii make: Entering directory ‘/home/Fusion/retroarch’ rm -f retroarch-salamander_wii.dol rm -f retroarch-salamander_wii.elf rm -f frontend/frontend_salamander.o frontend/frontend_driver.o frontend/drivers/platform_gx.o frontend/drivers/platform_wii.o libretro-common/file/file_path.o libretro-common/file/file_path_io.o libretro-common/hash/rhash.o libretro-common/string/stdstring.o libretro-common/lists/string_list.o libretro-common/lists/dir_list.o libretro-common/streams/file_stream.o libretro-common/vfs/vfs_implementation.o libretro-common/file/retro_dirent.o libretro-common/encodings/encoding_utf.o libretro-common/compat/compat_strl.o libretro-common/compat/compat_strcasestr.o libretro-common/compat/fopen_utf8.o libretro-common/file/config_file.o file_path_str.o verbosity.o wii/app_booter/app_booter.binobj wii/libogc/libfat/cache.o wii/libogc/libfat/directory.o wii/libogc/libfat/disc.o wii/libogc/libfat/fatdir.o wii/libogc/libfat/fatfile.o wii/libogc/libfat/file_allocation_table.o wii/libogc/libfat/filetime.o wii/libogc/libfat/libfat.o wii/libogc/libfat/lock.o wii/libogc/libfat/partition.o make -C wii/app_booter clean make[1]: Entering directory ‘/home/Fusion/retroarch/wii/app_booter’ rm -f app_booter.bin rm -f app_booter.elf rm -f crt0.o main.o …/…/libretro-common/crt/string.o make[1]: Leaving directory ‘/home/Fusion/retroarch/wii/app_booter’ make: Leaving directory ‘/home/Fusion/retroarch’ make: Entering directory ‘/home/Fusion/retroarch’ rm -f retroarch_wii.dol rm -f retroarch_wii.elf rm -f griffin/griffin.o wii/app_booter/app_booter.binobj make -C wii/app_booter clean make[1]: Entering directory ‘/home/Fusion/retroarch/wii/app_booter’ rm -f app_booter.bin rm -f app_booter.elf rm -f crt0.o main.o …/…/libretro-common/crt/string.o make[1]: Leaving directory ‘/home/Fusion/retroarch/wii/app_booter’ make: Leaving directory ‘/home/Fusion/retroarch’ make: Entering directory ‘/home/Fusion/retroarch’ /opt/devkitpro/devkitPPC/bin/powerpc-eabi-gcc -Wall -std=gnu99 -DGEKKO -DHW_RVL -mrvl -mcpu=750 -meabi -mhard-float -I. -Ilibretro-common/include -Ilibretro-common/include/compat/zlib -Iwii/libogc/include -std=gnu99 -DIS_SALAMANDER -DRARCH_CONSOLE -DHAVE_RARCH_EXEC -DGEKKO -Wno-char-subscripts -O3 -c -o frontend/frontend_salamander.o frontend/frontend_salamander.c make: *** [Makefile.wii.salamander:124: frontend/frontend_salamander.o] Error 1

HELP

WinterMute commented 4 years ago

@3po3po The answer to your issue was found in https://github.com/Fledge68/WiiFlow_Lite/issues/52#issuecomment-453493692 above.

However, since this calling tools with full path rather than adding the toolchain bin folder to the path first seems to be becoming an increasingly common pattern I've updated the windows binaries to include the requisite dll in the appropriate place. If you update your toolchain (open msys2 shell, via start->devkitpro->MSys2 and run pacman -Syu there) then hopefully it should "just work™"

3po3po commented 4 years ago

Thanks, there is still some "work™" to be done but it is 93% :)

/bin/sh: ar: command not found make[2]: [Makefile:51: liblua.a] Error 127 make[2]: Leaving directory '/home/Fusion/libretro-super/libretro-lutro/deps/lua/src' make[1]: [Makefile:99: libretro] Error 2 make[1]: Leaving directory '/home/Fusion/libretro-super/libretro-lutro/deps/lua/src' make: *** [Makefile:327: deps/lua/src/liblua.a] Error 2 cp "lutro_libretro_wii.a" "/home/Fusion/libretro-super/dist/wii/lutro_libretro_wii.a" p: cannot stat 'lutro_libretro_wii.a': No such file or directory 29 core(s) successfully processed: 2048 bluemsx snes9x2005 fbneo fceumm fmsx gambatte handy nestopia nxengine prboom quicknes snes9x2010 tyrquake vba_next vecx mgba genesis_plus_gx mednafen_lynx mednafen_ngp mednafen_pce_fast mednafen_supergrafx mednafen_vb mednafen_wswan mu gw prosystem 81 fuse 2 core(s) failed: stella lutro

* Salamader ---boot dol failed to COMPILE***

Fusion@DESKTOP-GL96P7F MSYS ~/retroarch $ make -f Makefile.wii.salamander /opt/devkitpro/devkitPPC/bin/powerpc-eabi-gcc -Wall -std=gnu99 -DGEKKO -DHW_RVL -mrvl -mcpu=750 -meabi -mhard-float -I. -Ilibretro-common/include -Ilibretro-common/include/compat/zlib -Iwii/libogc/include -std=gnu99 -DIS_SALAMANDER -DRARCH_CONSOLE -DHAVE_RARCH_EXEC -DGEKKO -Wno-char-subscripts -O3 -c -o frontend/frontend_salamander.o frontend/frontend_salamander.c /opt/devkitpro/devkitPPC/bin/powerpc-eabi-gcc -Wall -std=gnu99 -DGEKKO -DHW_RVL -mrvl -mcpu=750 -meabi -mhard-float -I. -Ilibretro-common/include -Ilibretro-common/include/compat/zlib -Iwii/libogc/include -std=gnu99 -DIS_SALAMANDER -DRARCH_CONSOLE -DHAVE_RARCH_EXEC -DGEKKO -Wno-char-subscripts -O3 -c -o frontend/frontend_driver.o frontend/frontend_driver.c /opt/devkitpro/devkitPPC/bin/powerpc-eabi-gcc -Wall -std=gnu99 -DGEKKO -DHW_RVL -mrvl -mcpu=750 -meabi -mhard-float -I. -Ilibretro-common/include -Ilibretro-common/include/compat/zlib -Iwii/libogc/include -std=gnu99 -DIS_SALAMANDER -DRARCH_CONSOLE -DHAVE_RARCH_EXEC -DGEKKO -Wno-char-subscripts -O3 -c -o frontend/drivers/platform_gx.o frontend/drivers/platform_gx.c In file included from frontend/drivers/platform_gx.c:26: wii/libogc/include/ogcsys.h:35:5: error: conflicting types for 'nanosleep' int nanosleep(struct timespec tb); ^~~~~ In file included from c:\devkitpro\devkitppc\powerpc-eabi\include\sys\stat.h:9, from c:\devkitpro\devkitppc\powerpc-eabi\include\sys\iosupport.h:11, from frontend/drivers/platform_gx.c:23: c:\devkitpro\devkitppc\powerpc-eabi\include\time.h:210:5: note: previous declaration of 'nanosleep' was here int nanosleep (const struct timespec rqtp, struct timespec *rmtp); ^~~~~ frontend/drivers/platform_gx.c: In function 'frontend_gx_get_environment_settings': frontend/drivers/platform_gx.c:189:4: warning: implicit declaration of function 'getcwd'; did you mean 'getw'? [-Wimplicit-function-declaration] getcwd(g_defaults.dirs[DEFAULT_DIR_CORE], PATH_MAX_LENGTH); ^~ getw make: *** [Makefile.wii.salamander:124: frontend/drivers/platform_gx.o] Error 1

Wiimpathy commented 4 years ago

As explained in the previous comments, you must use DevkitPPC r29.1 to compile Retroarch.

This devkit isn't available anymore and not supported by DevkitPro. You'll find it here : https://wii.leseratte10.de/devkitPro/devkitPPC/r29-1%20(2017)/

Not sure what you want to do, but if you just want to test the latest Wii builds, they can be found here : http://buildbot.libretro.com/nightly/nintendo/wii/

WinterMute commented 4 years ago

Please don't do this, we don't support old releases precisely because people run around refusing to fix relatively minor issues then advising each other to use random binaries that someone has "preserved". Mixing and matching random binaries you find on the internet can and will cause unresolvable issues for many users.

Ultimately you're doing everyone a massive disservice by teaching people to "work around" problems by breaking the tools devkitPro puts so much work into maintaining. Please stop.

As explained in the previous comments, you must use DevkitPPC r29.1 to compile Retroarch.

Not sure what you want to do, but if you just want to test the latest Wii builds, they can be found here : http://buildbot.libretro.com/nightly/nintendo/wii/

3po3po commented 4 years ago

Thank for both parties for replaying fast ...is this realy dead end .. To me it is not looking like that. What have to be done ?

Wiimpathy commented 4 years ago

Please dave don't be so closed-minded, you're not helping here. Retroarch is a big organisation now. They're free to use a previous devkit. And there are reasons for that. We won't discourse on this subject once again.

There are many cores to maintain. It's not always minor issues. I get your point about the devkit support. But then comes stupid reality. Who will check 80 emulators and fix potential bugs? You? By the way, Retroarch has an internal and lighter libogc. With latest devkits, the dols are bigger and some games won't work anymore!

I've done my homework. With R35, the neo core won't work anymore for the games using Nand VM. And the dol is now 4.1MB vs 3.8MB with R29.1! That's a big issue as there won't be enough RAM for some games. So why upgrade when things are working?

I'm sick of this useless discussion. Dave has a great knowledge and shared useful tools. But he rarely develop actual programs nowadays so maybe he forgot how painful it can be.

WinterMute commented 4 years ago

@Wiimpathy Retroarch's internal libogc isn't lighter, it's just a copy of an old libogc compiled with different flags.

I know exactly how painful developing actual programs can be. I've spent many, many hours helping people fix issues - time that could have been reduced a fair bit had it not been for the problems caused by this habit people have of just chucking old versions of tools and libraries over the top of a functioning toolchain install & breaking it. You have no idea just how many issues can be fixed by simply fixing the warnings - they're not always "just compiler noise" they often highlight what can be serious issues.

0.3MB doesn't seem like a huge issue when the Wii has ~80MB to play with, it shouldn't be insurmountable.

There are all sorts of reasons to upgrade - getting things to the point where they just compile out of the box without having to vandalise a carefully constructed toolchain is a good ambition. As always the primary issue I have with all this is teaching every new potential homebrew dev to not fix warnings and try to get codebases building with newer tools but rather just telling them to not bother and grab random archives of old tools and/or libraries then just overwrite stuff until things work. It doesn't encourage people to learn to code, to solve problems without increasing technical debt or consider the bigger picture and how their actions impact on everyone else.

I fully understand the dilemma but, y'know, emulators generally have a massive team of testers out there you don't have to do it all yourself. It isn't necessary to pre-emptively test everything.

WinterMute commented 4 years ago

@3po3po next step is figuring out which libogc version retroarch "froze" into their source tree & the differences from current libogc. Dropping the current libogc source in there may well work.

I'm not sure why we're talking about retroarch here though, how is this related?

Wiimpathy commented 4 years ago

Retroarch's libogc IS lighter. cf. https://github.com/libretro/RetroArch/commit/06ab96c622d0d6bd35a972ec6a3ddc0bf83f89e7#diff-d74bf7dbc82100cfc28fbf1c3654fd13

Their wiiuse is also different, I had to re-add WPAD_SetDataFormat in wpad.c when I've implemented lightgun : https://github.com/Wiimpathy/RetroArch/commit/744fac6777e5bcd4496f97715939056038131d29#diff-5b13478fa90a57c2d14db3b162d2edf6R1108 It's based on libogc 1.8.17.

And believe it or not but for the NeoGeo core, there's only around 500KB left for the largest games!

I wish you were right about the massive team of testers. But for the Wii(and surely other old platforms), almost nobody's testing. Untill last year nobody in the team had this console. That's a very low priority I guess and it's understandable. The problem is that almost all latest stable wii retroarch had real nasty bugs(menu crashing, video etc...)

WiiFlow is used as a (great) frontend for emulators. It's a plugin system where we can send arguments(game's path & options) to the specified emulator's dol file.

Wiimpathy commented 4 years ago

It's more 75MB by the way since a bit is reserved for IOS. See https://wiibrew.org/wiki/Memory_Map In Retroarch it becomes unstable around 74MB. And the scanlines overlay feature is unusable at about 72MB.

Here are examples of why RAM is also a problem here:

The King of Fighters 2003. Zip extracted : 93.8MB Metal Slug 3 : 93.1MB SNK vs Capcom : 92.8MB Garou: Mark of the Wolves : 92.8MB etc... Get it?

3po3po commented 4 years ago

Hello people long time ago i was assembler coder on Amiga and generally Motorola my tool was ASM-ONE heil :) almost 20yrs ago last 2 year i am in some condition to make effort to code again and i made some tutorials on obj programming since C i know a little. Anyway i remember the days where i have to lover color output to just 2 color 1 bit plane to squeeze --20kb more just obtain more chip ram for mod(music). As i understand good there is suggestion now to drop libogc (the one from retro arch team to the source and try to compile also i understand from wimphaty explanation that you have successfully compiled on r35 and i cannot (you made comparation between 2 compile builds in size) Yes it is great to see when things are going in direction of RESOLUTION i landed on Nintendo very probably cause i am emotionally attached for motorola cpus my last one was ppc603 and cpu inside wii to mi is big monster :)

Long Live Motorola :)

3po3po commented 4 years ago

So what about comparison in size between 2 compilers ... to me is not working?

Wiimpathy commented 4 years ago

It is NOT working with R35. Sorry, but I won't repeat the same stuff a million times.

First, try to compile like it's supposed to be with R29.1.

Then, when you succeed, you'll be able to experiment with latest devkits if you really want to. There will be a lot of errors/bugs. You can ask support @devkitpro. Goo luck!

3po3po commented 4 years ago

So it is compiling but with bugs .... ???

Wiimpathy commented 4 years ago

Wow, you're going to make me mad dear colleague.

STANDARD & EASY WAY: Compile Retroarch with R29.1. No compile errors. No new bugs.

THE HARD WAY (Or how to break cores): Compile with R35. Compile errors (threads...) and lot of warnings. And bloody bugs. Larger executable. Some games won't work anymore! Oh what about GCC performance? See ekeke comment: https://github.com/ekeeke/Genesis-Plus-GX/issues/260#issuecomment-461129726

Do as you want. Ask WinterMute how to fix compile errors if you chose the hard way and has infinite time.

I don't understand what you want to do exactly.

3po3po commented 4 years ago

Wiimpathy what OS you use for dev

Wiimpathy commented 4 years ago

Linux.

Fledge68 / WiiFlow_Lite

Cant compile on latest devkitpro r33 #52