removing requirements for sys/time.h + sys/socket.h breaks using any lib which includes those "incidentally"
Zarklord opened this issue · 20 comments
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
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,
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...
Could you try now? I tested only a trivial application with newlib but it seems to be working...
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
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...
Can you try replacing -msdata with -mno-sdata here:
https://github.com/decaf-emu/wut/blob/master/cmake/wut-toolchain.cmake#L47
well it compiled... ill test if it worked...
nope it crashed my wii u...
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.
Would be good if you could put your source somewhere and I can use it for testing.
yes i can do that...
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/
i also believe the liboGC stuff was a requirement from a long time ago and since isnt used at all...
@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.
@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...
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...
Could that be a problem with how both wut and libiosuhax are setting up devoptap?
quite possibly... i don't know much about the inner workings of libiosuhax though.
is the crt-lite the intended fix for this issue?
edit: accidental close
Nope it's unrelated, sorry!