Re: MacPorts vs. Apple compiler issues, Handle
Could you refer me to the beginning of this discussion please? I am also involved in AF project :) > On Mar 19, 2024, at 10:11 AM, Joshua Root wrote: > > (Moving to macports-dev as it is a better fit for this topic.) > > On 18/3/2024 22:50, Riccardo Mottola wrote: >> I will do another compilation reducing the optimization level. GCC has an >> issue where beyond gcc6 certain optimizations need to be disabled, or AF >> crashes. > > Issues that only appear at higher optimisation levels also often involve > undefined behaviour. > >> Exception Type:EXC_BAD_ACCESS (SIGSEGV) >> Exception Codes: KERN_INVALID_ADDRESS at 0x7ffe2007 > > So here is what happened: SIGSEGV means the program tried to access memory > that it should not have. The page was not mapped or had the wrong permissions > for what it was trying to do. The memory address that it attempted to access > is also shown. > >> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread >> 0 XUL 0x00010f5468e1 >> nsWindowWatcher::OpenWindowInternal(mozIDOMWindowProxy*, char const*, char >> const*, char const*, bool, bool, bool, nsITabParent*, nsIArray*, >> nsIDocShellLoadInfo*, mozIDOMWindowProxy**) + 273 > > And this is where it happened. Since this is not a full debug build, there is > no line number information, but you at least know which method is doing the > bad memory access. > > - Josh
Re: MacPorts vs. Apple compiler issues, Handle
(Moving to macports-dev as it is a better fit for this topic.) On 18/3/2024 22:50, Riccardo Mottola wrote: I will do another compilation reducing the optimization level. GCC has an issue where beyond gcc6 certain optimizations need to be disabled, or AF crashes. Issues that only appear at higher optimisation levels also often involve undefined behaviour. Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x7ffe2007 So here is what happened: SIGSEGV means the program tried to access memory that it should not have. The page was not mapped or had the wrong permissions for what it was trying to do. The memory address that it attempted to access is also shown. Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 XUL 0x00010f5468e1 nsWindowWatcher::OpenWindowInternal(mozIDOMWindowProxy*, char const*, char const*, char const*, bool, bool, bool, nsITabParent*, nsIArray*, nsIDocShellLoadInfo*, mozIDOMWindowProxy**) + 273 And this is where it happened. Since this is not a full debug build, there is no line number information, but you at least know which method is doing the bad memory access. - Josh
Re: SDL2 on PowerPC: it works now, can we fix joystick for it?
UPD. Judging from my notes, it actually may be fixable now, since gcc upstream addressed the stopping bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522 Need to rebuild gcc13 adding this patch and see if it helps. On Mon, Mar 18, 2024 at 12:34 AM Sergio Had wrote: > Upon sorting X11 installation, turned out that most of X11 ports actually > work with GUI on PowerPC, including SDL2 and VLC. > > However, most of Macports dependents of libsdl2 are games and emulators, > and they need a joystick module, which is broken quite badly in SDL 2.1+. > So those ports will build but won’t start, complaining about joystick > support missing. > > Even without that, SDL is useful (SDL video out works with VLC now), and > personally I do not really care for games’ support, but apparently there is > a demand, so why not make someone happier :) > > Can we find a way to fix it? >
