Page 1 of 1

devkitARM release 50

Posted: Sat Dec 15, 2018 11:46 pm
by WinterMute
devkitARM release 50 is now available via pacman. Use sudo (dkp-)pacman -Syu to update or sudo (dkp-)pacman -S devkitARM to install.

devkitARM release 50
  • Updated binutils to 2.31.1
  • Updated gcc to 8.2.0
  • Updated gdb to 8.2

Re: devkitARM release 50

Posted: Fri Dec 21, 2018 12:45 am
by WinterMute
50-2 corrects a minor header issue.

Re: devkitARM release 50

Posted: Fri Dec 28, 2018 11:45 pm
by WinterMute
50-3 & now 50-4 correct the unintended consequences of the header fixes.

Re: devkitARM release 50

Posted: Wed Jan 02, 2019 6:15 pm
by PypeBros
I note that devkitARM_r50 contains a curious warning message about use of __sync_synchronize().

Do you know of any context that lead to that line to be present? Is there any multi-thread-capable platform that makes it meaningful ? Would I be safe for NDS to redefine __sync_synchronize() as an empty function in my own code if I want to avoid the compiler to stop when -Werr is used ?

[mod: edited to remove confusing links]

Re: devkitARM release 50

Posted: Sat Jan 12, 2019 1:54 pm
by bim
So, uhm. I tried updating via the .pl and pacman, but it tells me for gba-dev r49-2 is the current version? What am I doing wrong?

Re: devkitARM release 50

Posted: Tue Jan 15, 2019 3:35 pm
by WinterMute
PypeBros wrote:I note that devkitARM_r50 contains a curious warning message about use of __sync_synchronize().

Do you know of any context that lead to that line to be present? Is there any multi-thread-capable platform that makes it meaningful ? Would I be safe for NDS to redefine __sync_synchronize() as an empty function in my own code if I want to avoid the compiler to stop when -Werr is used ?

[mod: edited to remove confusing links]
It's a gcc built-in memory barrier which only emits a call to __sync_synchronize on platforms which don't have memory barrier instructions. In your case you can compile your code with

Code: Select all

-fno-threadsafe-statics
and not worry about it.

Primarily the link warning is there to see how much it turns up for people (answer so far: not much) and to provide me with reminders to check what needs to happen should we implement threading with libnds (something under discussion but may not happen)

Please try to exercise patience when asking questions & not rush off elsewhere to be confused by responses from people unfamiliar with the tools.

Re: devkitARM release 50

Posted: Tue Jan 15, 2019 3:46 pm
by WinterMute
bim wrote:So, uhm. I tried updating via the .pl and pacman, but it tells me for gba-dev r49-2 is the current version? What am I doing wrong?
The perl scripts were deprecated quite some time ago & should no longer be used. As for pacman, I don't know. You could try forcing a db refresh with -Syyu instead of just -Syu.

Let me know if you still can't get the latest tools it might need more investigation.

Re: devkitARM release 50

Posted: Wed Jan 16, 2019 9:49 pm
by PypeBros
WinterMute wrote:
PypeBros wrote:I note that devkitARM_r50 contains a curious warning message about use of __sync_synchronize().

It's a gcc built-in memory barrier which only emits a call to __sync_synchronize on platforms which don't have memory barrier instructions. In your case you can compile your code with

Code: Select all

-fno-threadsafe-statics
and not worry about it.

Primarily the link warning is there to see how much it turns up for people (answer so far: not much) and to provide me with reminders to check what needs to happen should we implement threading with libnds (something under discussion but may not happen)
Ok, that seems to work. Thanks. If you can think of a keyword that would make it obvious the warning is introduced by devkitpro team in such case, it might avoid confusion in the future.