devkitPro / wut

Let's try to make a Wii U Toolchain / SDK for creating rpx/rpl.
zlib License
244 stars 52 forks source link

removing requirements for sys/time.h + sys/socket.h breaks using any lib which includes those "incidentally" #51

Closed Zarklord closed 6 years ago

Zarklord commented 7 years ago

what the title says... by removing those dependiences(which dont need to be removed) it breaks using just about any devkitPPC header file as most files somewhere down the line include sys/time.h or sys/socket.h and now you have two places #defining the same value to take this one step further there isnt a reason to not use: `#include <sys/time.h>

include <sys/socket.h>` in nsysnet/socket.h cause devkitPPC is a requirement for using WUT

exjam commented 7 years ago

I think the real problem here is that for when using wut you really should not be using devkitPPC's headers in their current state. There's no guarantee that the defines in sys/socket.h match up with what the Wii U expects. I understand this is pretty unavoidable if you're using wut with an existing codebase (which unfortunately I never do, so I never end up testing this situation), but for that scenario then we really need to look at our own newlib system implementation targeted at the Wii U.

Also it'd be great to modify the devkitPPC buildscripts to actually setup GCC in a way which generates code that is properly compliant with the Wii U and does not require a bunch of hacks to work around, simple stuff such as generating jump tables with GOT offsets breaks loading code on the Wii U due to generating unsupported relocation types,

Zarklord commented 7 years ago

yup I agree that if we had a wii u specific lib it would be better... but until we do breaking support for devkitPPC is a sure cause for people not to use the latest repo I personally reverted nsysnet back to its working state(pre dependencies removed) for me since its unusable in its current state...

exjam commented 7 years ago

Could you try now? I tested only a trivial application with newlib but it seems to be working...

Zarklord commented 7 years ago

all the code compiles but i get this error: c:/devkitpro/devkitppc/bin/../lib/gcc/powerpc-eabi/4.8.2/../../../../powerpc-eabi/bin/ld.exe: CMakeFiles/Save_Manager.dir/src/system/memory.c.obj: relocation R_PPC_EMB_SDA21 cannot be used when making a shared object CMakeFiles/Save_Manager.dir/src/system/memory.c.obj: error adding symbols: Bad value collect2.exe: error: ld returned 1 exit status Make[2]: *** [Save_Manager] Error 1 Make[1]: *** [CMakeFiles/Save_Manager.dir/all] Error 2 Make: *** [all] Error 2

Zarklord commented 7 years ago

for reference the c/h that is there is this https://github.com/Maschell/GX2_GUI_Template/blob/rpx-channel/src/system/memory.c https://github.com/Maschell/GX2_GUI_Template/blob/rpx-channel/src/system/memory.h edit: to note this isn't my project but rather what my project is based off of...

exjam commented 7 years ago

Can you try replacing -msdata with -mno-sdata here: https://github.com/decaf-emu/wut/blob/master/cmake/wut-toolchain.cmake#L47

Zarklord commented 7 years ago

well it compiled... ill test if it worked...

Zarklord commented 7 years ago

nope it crashed my wii u...

exjam commented 7 years ago

Maybe this is the problem (from GX2_GUI_Template): "In order to build this application, you need the custom liboGC and portlibs modified/created by dimok. You can find them on the loadiine_gx2 repo"

This might be interfering - libogc should never be used on the Wii U. portlibs would probably work ok though.

exjam commented 7 years ago

Would be good if you could put your source somewhere and I can use it for testing.

Zarklord commented 7 years ago

yes i can do that...

Zarklord commented 7 years ago

just a note you need to setup libiosuhax https://github.com/dimok789/libiosuhax just do "make wut" then "make install" repo here: https://github.com/Zarklord1/Save_Manager/

Zarklord commented 7 years ago

i also believe the liboGC stuff was a requirement from a long time ago and since isnt used at all...

CreeperMario commented 7 years ago

@Zarklord1 Now that it compiles and links successfully, I would assume that libiosuhax is the problem here. Even before CMake was introduced, I was unable to get an RPX with libiosuhax linked in to boot successfully. Not sure why its even a static library to begin with.

Just noting that the changes within the last week or so once again break the WUT example projects. Doing what @exjam stated above (removing -msdata from the toolchain file) seems to repair the examples. Not sure if they're being linked to newlib or not, but they seem to work on my console at least.

Zarklord commented 7 years ago

@CreeperMario I literally was using libiosuhax before these changes with perfect success in a rpx app so that might be the issue but it would have to be caused by these changes...

Zarklord commented 7 years ago

well i have done some poking and can make it compile and run if i comment out all libiosuhax stuff... but the program crashes here: https://github.com/Zarklord1/Save_Manager/blob/master/src/utils/MetaXML.cpp#L17 which is called from here: https://github.com/Zarklord1/Save_Manager/blob/master/src/menu/SaveWindow.cpp#L139 so it would have to be these newlib changes breaking TinyXML from properly reading the file... edit: its not TinyXML's fault any fs access through libiosuhax instantly breaks the program...

exjam commented 7 years ago

Could that be a problem with how both wut and libiosuhax are setting up devoptap?

Zarklord commented 7 years ago

quite possibly... i don't know much about the inner workings of libiosuhax though.

Zarklord commented 7 years ago

is the crt-lite the intended fix for this issue? edit: accidental close

exjam commented 7 years ago

Nope it's unrelated, sorry!