Given nobody's stepped forward to fix Nintendont's issues that have plagued it on the latest versions on dkP, I can only assume it's very non-trivial to debug and fix, to a point where effort is better spent remaining on the same version of the tools rather than upgrading and attempting to validate everything afterwards. I have to deal with that enough at my actual job and its insanely long product lifecycles, and honestly console homebrew isn't much different. Sticking with older toolchains and containerizing them is a valid strategy. I've run out of patience with Intel/TI/etc's toolchain maintenance/licensing practices, which is why I especially don't appreciate a FOSS project playing hard to get with older versions/migration. Especially given FOSS tools *usually* keep old versions of everything around forever and want things preserved (e.g. this release of GCC from 1987 https://ftp.nluug.nl/languages/gcc/old-releases/gcc-1/gcc-0.9.tar.bz2 ).i hard disagree.
their "whining" is correct and a hard fork is a stupid idea seeing how much work is put into the toolkits provided by devkitPRO.
they work their asses off, pay huge bills for hosting only to have hostile, problematic, forks and half arsed guides or help cause users to barrage them, who are doing this in their free time mind you, with issues of broken and not sane installation because of projects and behavior like this.
also: to this day, i have yet to see a project that does not have stupid or insane programming practices that breaks with updates of a mature devkitPRO library (unless its caused by nintendo's changes like with switch's controls scheme). things like retroarch including an ancient libogc version in their repo, projects using internal libogc functions or just doing stuff that are fragile af.
all of that would not be an issue had they used decent and sane code or not be from ~2 decades back when libogc wasn't mature.
and im not saying the libraries provided by devkitPRO are perfect, far from. (libogc is in the bad shape, but libnx is lovely).
its because they are fixing said issues that sometimes, yes, things will break. but everyone benefits from said fixes if developers, or whomever is compiling, would update the code.
as for your statement of "they don't give a damn about maintaining compatibility", then you have NO idea how they work and what decisions they make and are blinded by your own hate/anger. as a maintainer of libogc and being in close contact with them i can tell you they most certainly do care or else libogc would look completely different now and not be as shitty as it is. but that breaks compatibility, so we dont do that (same with libnds & libgba)
this is true, and will always be true.
they would rather have homebrew be updated for latest tools (and therefor get clean, good code) but it all depends on who you end up talking to and what your experience in coding is. i know wintermute can sound hostile, and i can only say that you don't know what has pushed him to be like that and what kind of shitty code & setups they get to look at. this is a topic on its own, and this might not be the best place for that.
i would love to help people to update their wii/gc code and im sure i would be friendly chat, so keep in mind that who you talk to is more important than "the whole organization" (which is a lot more people than you'd think). a few "sour" apples, a community does not ruin (i mean, look at this shithole of a forum/website. most users would say this isn't a shithole. not me, but some users)
also, they kinda can't ignore the mirrors, seeing how much problems it gives them. be it bills and traffic control or people copy pasting bad code from some random place and then publicly saying its all broken because they copied bad code from some random mirror/fork/project. Things are a lot more complex than that, sadly.
i could go on and on about the inner workings of devkitPRO, and its problems, but thats kinda out of scope here and i'd love to have a decent convo about it, if youre open to it and start the convo to have a meaningful convo instead of just bashing.
i don't know anything about any nintendon't issues caused by a devkitPPC/libogc release. all i know about nintendon't is that its code is messy and does some questionable stuff so im not surprised it breaks somewhere. 8/10 im sure its one of the many warnings gcc throws at it. that said, Cios also isn't updated over all these years and devkitARM also throws a shit ton of warnings on it. i looked at its code once and it was full of questionable stuff. i sure hope starstruck will prove its stupidity but thats a few years off.Given nobody's stepped forward to fix Nintendont's issues that have plagued it on the latest versions on dkP, I can only assume it's very non-trivial to debug and fix, to a point where effort is better spent remaining on the same version of the tools rather than upgrading and attempting to validate everything afterwards. I have to deal with that enough at my actual job and its insanely long product lifecycles, and honestly console homebrew isn't much different. Sticking with older toolchains and containerizing them is a valid strategy. I've run out of patience with Intel/TI/etc's toolchain maintenance/licensing practices, which is why I especially don't appreciate a FOSS project playing hard to get with older versions/migration. Especially given FOSS tools *usually* keep old versions of everything around forever and want things preserved (e.g. this release of GCC from 1987 https://ftp.nluug.nl/languages/gcc/old-releases/gcc-1/gcc-0.9.tar.bz2 ).
yes, yes you can trust those. the docker containers are meant for CI builds, because people were downloading and installing devkitPRO's toolkits in CI builds, which is stupid as hell. this is why docker containers exist, and why they were created.Look, all I really want is the ability to bisect code generation myself, and roll back to older versions to facilitate that bisect by having some working version as a ground truth. To me, it's insane that dkP makes it that difficult to perform the standard software development process of a bisect between toolchain versions. Even though some versions are half broken, even TI currently attempts to provide older releases of their toolchain/IDE. I know dkP at least offers docker containers, and I applaud them for seemingly not deleting the older tags, but these are a fairly recent addition, and can we trust that these tags will never be deleted?
"dkp" is a company, not a tool. i assume you mean devkitARM if youre talking about ds.This homebrew for example seems to have broken some time between dkP from 2017 and 2022. I could be missing something, but it isn't doing anything obviously wrong that I could quickly identify:
https://gbatemp.net/threads/bad-apple-for-the-nintendo-ds.466504/
Edit: oh, and as a bonus, the new dkP build only crashes on hardware. Runs fine on emulators. Very easy to debug.
easy. gba scene was a mess, and had a messy merge of toolkits to make devkitARM & devkitPRO in general. nobody knew what they were kinda doing then. with every generation of console or handheld step by step they started to make better code, more optimized and with end users in mind. cooperation with devkitPRO has gotten us some advantages stuff.I will say, yes, libnx and libctr are pretty cool. It's just odd that something that should be as mature as libnds/the rest of the toolchain for it is still at a point where it can break between 2017 and 2022.
i personally don't know the history between TWLMenu & devkitPRO so i can not comment on this. i'd need to check or dig for that to know what happened (from both sides) to say if it was right or not. could have been that they were wrong, or somebody in TWLMenu was pissing of/working against what devkitPRO was building/doing. many options.And while I could probably ask for support in this case, given dkP, or at least a certain individual in a position of power in dkP, has apparently completely barred people from support/contributing for simply being involved with TWLMenu for example, why should I even bother? Who's to say what other projects are "problematic" enough by simply existing to warrant a github-wide block (maybe Nintendont, ULGX)? This is clearly an instance where I'd say "a few sour apples" *can* ruin the community.
Maybe I'm missing something here too, but at a surface level, it appears as simple as "TWLMenu dev -> blocked". Locking a seemingly valid PR as "too heated" (that seems to have been reworked and merged by dkP staff later) without any visible trouble doesn't reflect well on the organization.
i can't say youre wrong, and there is a reason why some of us have started doing some public work, and ive been trying to improve relations with communities of the wii. im here on this forum (sometimes, because fuck gbafail) and a few discords (including the awesome /r/wiihacks crew) and im a firm believer playing more open book could work in some advantages. i realize that communications have been bad with devkitPRO and i would like to see that changed because i understand both sides and can't blame either side either.Yes, people will write bad code and use tools poorly. And yes, I fully understand that well over a decade of that can drive a man to madness. But that is the point where one needs to step back and let others handle the first line of support rather than advertising themselves as the first point of contact. Maybe document some of these edge cases or obscure migration steps on the wiki. idk. I've seen communities die at the hand of someone in power who couldn't take a back seat from user support, and while this may not be one of those situations yet, I've talked to enough people who have actively avoided engaging with dkP for these very reasons.
Maybe the mirror bills thing was valid pre-pacman, but given all of dkP's heavy infrastructure is hosted by github/docker now, bills aren't a reason to not scrape/mirror anymore, beyond the forum and wiki. People will always fuck up tutorials and whatever else, so I wouldn't use that as a reason to withhold older tools from people who know what they're doing.
What about when it's libogc internal code that breaks?and clearly you don't have to deal with the questions of people who fuck up their installations or compilation by using said tutorials or those who refuse to update because "their [shitty] code no longer compiles right", instead of reporting the issue (i currently have 55 unread messages on the forum and i am NOT looking forward to those)
I'm still of the belief that outright nuking older versions of the tools is never acceptable. Yes, managing support can be terrible. Yes, you can hide the older versions and make it very clear that no support is provided, or demand they retry in a clean modern devkitPRO environment set up in a very specific way. These are solved issues that other projects have dealt with. Just imo, if you want more competent FOSS people to join your FOSS toolchain project, stick to standard FOSS practices. There are times when user noise can be ignored.i don't know anything about any nintendon't issues caused by a devkitPPC/libogc release. all i know about nintendon't is that its code is messy and does some questionable stuff so im not surprised it breaks somewhere. 8/10 im sure its one of the many warnings gcc throws at it. that said, Cios also isn't updated over all these years and devkitARM also throws a shit ton of warnings on it. i looked at its code once and it was full of questionable stuff. i sure hope starstruck will prove its stupidity but thats a few years off.
i know old versions are usually available with FOSS tools, but devkitPRO was semi forced to do what they did. do you know how many people did (and still are) knocking on their door after fucking up their installation environment in the most fucked up ways? hell, some libraries still require people to do so. you should never have to touch the devkitppc or libogc directories manually. ever.
in all these years, i have never had any of my applications break due to updates. at worst i had to deal with things being renamed or improved but never magic "i break now" stuff, and this includes starstruck which has many low level starlet code. that just means bad code was written, or code that doesn't know what a compiler should and can do. and tools like nintendont and cios should be written by people that do know what it'll do or maintained version by version just by the very nature of the tool.
this is also has been my annoyance with 9/10 tools that are here on gbafail.
also, with "dkP" i assume you mean devkitPPC? because devkitPRO is an organisation, not a tool.
I'm just forced to question it because the older toolchains used to be available too. It doesn't instill a good sense of trust.yes, yes you can trust those. the docker containers are meant for CI builds, because people were downloading and installing devkitPRO's toolkits in CI builds, which is stupid as hell. this is why docker containers exist, and why they were created.
i personally can't see a reason as why downgrading would be needed, just debug and fix the code. but incase you do have a nasty issue and want to revert, fix the issue and upgrade again. its stupid to say on old versions, and this is what people are doing, while fucking up their installations...
One of my main issues is that this is that breakage is something I've encountered more often than not. Which is fine, I don't expect old projects to keep up with new toolchains. And then for any other project, at my job or elsewhere, I would then go to construct a build environment using an old version of Ubuntu in a container, or wherever else. And then I get frustrated because I can't find the old versions of the tools. There's enough problems to deal with when attempting to maintain/upgrade code without having to fight the tools."dkp" is a company, not a tool. i assume you mean devkitARM if youre talking about ds.
i can't say i know ds hardware well, but keep in mind generally emulators are not really accurate. only emulators i know i can say are accurate and should be used for debugging is mgba & bgb. the issue is annoying, but the code seems to do a few weird things. i do know a few data access problems were fixed in devkitARM/libnds that allows for faster code and is more accurate to what the hardware specs are. if a problem comes up, i'd check what the difference between the app and the examples is. they are often used as a test to check if code still works.
im not saying this isn't a problem, don't get me wrong. i just think it gets overblown a bit because many don't know or realize what is changed in the toolkit. is this problem even reported? do they know about it? important questions imo
The big thing is optics. I personally make a conscious effort to avoid projects where locking gets seemingly abused as it hinders discussion and requires going through extra steps to attempt to address; where seemingly legitimate bug reports, feature requests the submitter intends to work on for tracking progress, or good-faith contributions get locked and closed with minimal public discourse.i personally don't know the history between TWLMenu & devkitPRO so i can not comment on this. i'd need to check or dig for that to know what happened (from both sides) to say if it was right or not. could have been that they were wrong, or somebody in TWLMenu was pissing of/working against what devkitPRO was building/doing. many options.
that said, generally if a PR is locked its because of a heated discussion or because the PR has bad code that does is not up to standards. again, i don't know what happened so im just pulling on straws here and can't comment on it further.
Again, optics. I believe many of us perceive devkitPRO as rather hostile. And honestly, I believe someone new shouldn't need to know Wintermute's history. Users need a better onboarding experience if that is the case. New contributors generally don't go straight to Torvalds who is also known for his wonderful ability to call out bullshit. They start on support forums or IRC and work their way up as needed. Something needs to change, and yes, a community is a very important thing to have. Again, yes, users are shitty. There's no changing that. But I am saying there are better ways to deal with the situation than how it is being handled now. Legitimate users of the toolchain are being negatively affected by devkitPRO's reactions to what they see as users doing shitty things.i can't say youre wrong, and there is a reason why some of us have started doing some public work, and ive been trying to improve relations with communities of the wii. im here on this forum (sometimes, because fuck gbafail) and a few discords (including the awesome /r/wiihacks crew) and im a firm believer playing more open book could work in some advantages. i realize that communications have been bad with devkitPRO and i would like to see that changed because i understand both sides and can't blame either side either.
i still believe devkitPRO should be the point of contact, but they require people to help maintain it because they alone can't, and shouldn't do so. the organization needs a community of people that know what they are doing. what i mean with this is like how ive been trying to look after libogc, even though i don't consider myself to be worth of it haha.
if you post something on that repo, i will probably be the first point of contact. imo, every part of the toolkits and libraries needs this but its hell trying to find people who's vision aligns with devkitPRO and knows what they are saying.
also, where do you think the pacman packages or docker containers are hosted? its on their own host, not github.
and clearly you don't have to deal with the questions of people who fuck up their installations or compilation by using said tutorials or those who refuse to update because "their [shitty] code no longer compiles right", instead of reporting the issue (i currently have 55 unread messages on the forum and i am NOT looking forward to those)
Look, i believe the problem with devkitPRO is a problem on both ends of the line. both Wintermute being misunderstood because the lack of knowledge/history and people like you who bash on devkitPRO because they are doing weird things (why the hell do you need to compare a toolkit/gcc version. there is also ghidra for that) but also don't fully understand what is going on behind the curtains...
see, and this is where misinformation, and euh... bullshit claims begin and where things go wrong. devkitARM still has big endian support and compiling stuff for starlet still works just fine ...I'm still of the belief that outright nuking older versions of the tools is never acceptable. Yes, managing support can be terrible. Yes, you can hide the older versions and make it very clear that no support is provided, or demand they retry in a clean modern devkitPRO environment set up in a very specific way. These are solved issues that other projects have dealt with. Just imo, if you want more competent FOSS people to join your FOSS toolchain project, stick to standard FOSS practices. There are times when user noise can be ignored.
In regards to Nintendont in particular, there are a couple of issues. But as I understand it, the big one stemming from devkitPRO's policies is this:
What is the solution here? The currently-shipped gcc itself still supports big-endian ARM, and Nintendont has just resorted to uploading compiled the required static library/object files + CRT stub to the project itself. Hardly ideal, but that's the state of things.
- Nintendont runs on Starlet by hijacking IOS58 and patching it to load its own code
- Starlet is big-endian ARM
- devkitARM dropped support for big-endian ARM, which is 100% understandable
- devkitPRO nukes the older releases and has DMCA'd FIX94's upload of a compatible devkitARM in the past
(and fwiw the main issue on newer toolchain releases is Nintendont hanging/freezing the Wii when exiting from a game).
time will tell, but im sure its a-ok. and until that time, trust the system man.I'm just forced to question it because the older toolchains used to be available too. It doesn't instill a good sense of trust.
thats the thing, you don't have to fight the tools. why don't you do what everyone else does : build , fix errors, build, fix errors, build, fix warnings, build, fix more warnings, test and fix. that said, i can understand the need for old tools then but this is not the reason they dislike the whole old versions thing. what they do dislike is exactly what was in nintendont and guides and people telling random people to install the old versions. that is a huge nono and its better to just install latest and port the app. is it hard? yes, but you'll end up having wasted less time and probably refactoring code that needed refactoring to begin with.One of my main issues is that this is that breakage is something I've encountered more often than not. Which is fine, I don't expect old projects to keep up with new toolchains. And then for any other project, at my job or elsewhere, I would then go to construct a build environment using an old version of Ubuntu in a container, or wherever else. And then I get frustrated because I can't find the old versions of the tools. There's enough problems to deal with when attempting to maintain/upgrade code without having to fight the tools.
i can understand that, and optics is a thing. you see those cases from the end users point of view, i see them from the devkitPRO point of view, as i know what they are fighting sometimes. you need to moderate discussions at some point because youre putting things out there that are just... bad. and i see this in my professional life too. developers that copy paste shit from internet (stack overflow, github, ... ) without knowing what they are copy pasting.The big thing is optics. I personally make a conscious effort to avoid projects where locking gets seemingly abused as it hinders discussion and requires going through extra steps to attempt to address; where seemingly legitimate bug reports, feature requests the submitter intends to work on for tracking progress, or good-faith contributions get locked and closed with minimal public discourse.
this is why i want to change to face of libogc and devkitPPC but doing communications. i understand both sides, and want to get some hands to be shaken again haha.Again, optics. I believe many of us perceive devkitPRO as rather hostile. And honestly, I believe someone new shouldn't need to know Wintermute's history. Users need a better onboarding experience if that is the case. New contributors generally don't go straight to Torvalds who is also known for his wonderful ability to call out bullshit. They start on support forums or IRC and work their way up as needed. Something needs to change, and yes, a community is a very important thing to have. Again, yes, users are shitty. There's no changing that. But I am saying there are better ways to deal with the situation than how it is being handled now. Legitimate users of the toolchain are being negatively affected by devkitPRO's reactions to what they see as users doing shitty things.
nah, the packages are hosted on the server. this is why comcast connections had a lovely issue recently of not being able to download them. the 'download' in the hostname triggered comcast to inject their shit into the connection and fucking it all up. the docker is part of their stuff, yes.I apologize, I do see the pacman packages are indeed hosted on the website. I was confused and assumed it was the pacman metadata only. Is the docker account sponsored by devkitPRO? As I understood it the docker hub images pull from docker hub's servers which should be free for FOSS.
I will reiterate, comparing builds between toolchains is not an uncommon practice. It will certainly point you in a better direction when comparing generated code rather than just digging into Ghidra blind, and if you're lucky, you can read through the commits of GCC itself/the supporting toolchain to figure out what in particular may have changed. More information is good.
thats the thing, you don't have to fight the tools. why don't you do what everyone else does : build , fix errors, build, fix errors, build, fix warnings, build, fix more warnings, test and fix. that said, i can understand the need for old tools then but this is not the reason they dislike the whole old versions thing. what they do dislike is exactly what was in nintendont and guides and people telling random people to install the old versions. that is a huge nono and its better to just install latest and port the app. is it hard? yes, but you'll end up having wasted less time and probably refactoring code that needed refactoring to begin with.
and in this case its the new versions pointing out your code is really not that great. but i repeat myself heheIt's hard for the compiler to see something is wrong when you're just *(vu32*)0x0BADC0DE everywhere.
i still believe devkitPRO should be the point of contact, but they require people to help maintain it because they alone can't, and shouldn't do so. the organization needs a community of people that know what they are doing. what i mean with this is like how ive been trying to look after libogc, even though i don't consider myself to be worth of it haha.
as for the DMCA, i understand why they did it. it was a stupid move to upload that to the repo and it was pushing people to do the same. that is not ok and very bad practices. wouldn't be surprised that is why they did it, but don't quote me on it. so the solution? just use latest devkitARM and fix that code
$DEVKITPRO
to point to an older installation directory actually works very well!brew install dkp-homebrew-tools
" to just pull in everything. And when there are known bugs, other users can make posts and articles about them, without having to worry about it being copyright-striken or escalating. If a community maintainer or set of instructions is outdated, HB devs can judge that for themselves by looking at the date and comments if this guide or another guide makes more sense.no, it shouldn't be. what is broken?Studios-pancake have a incompatibility with latest devkitA64 so downgrading using your repo is the way to go now.
my C++ knowledge is not good enough, but this seems to be an issue of specs not being followed by the compiler before and it is now (since its now using GCC 13 )
Thanks, yes I am on the same train, I really don't know too much about C++ the strange thing is if your environment have devkitA64 r21-3 the same code build fine, but once you update to devkitA64 r22-1 the exact same code of Studious generate that error.my C++ knowledge is not good enough, but this seems to be an issue of specs not being followed by the compiler before and it is now (since its not using GCC 13 )
see : https://stackoverflow.com/questions/11069108/uint32-t-does-not-name-a-type
if you want to use std::uint32_t you should include <cstdint>. this was always the case, but GCC used implicitly include it
this has been changed so that code need to actually include what they will use.
see : https://gcc.gnu.org/gcc-13/porting_to.html
... this was 5 min of looking around and asking 1 C++ developer...