@sTix Wow! Did you apply patches from adtools which were done for early versions of GCC in full? If so, I may try to build Odyssey with it as well!
Dare I ask if you are willing to deal with some issues later ?:)
I also see you disable gcc17++ in gcc9 due to clib2 limitations, but what about newlib ? (basically, most stuff on os4 use newlib, clib2 for vim was mostly as an exception)
edit: and last question, in gcc10 threading disabled, is it mean whole threading (-athread=native and stuff), or c++ threading?
Wow! Did you apply patches from adtools which were done for early versions of GCC in full? If so, I may try to build Odyssey with it as well!
For gcc 9 all patches are applied. The only thing that had to go was c++17 (but that obviously isn't a part of the original patchset) due to limitations in clib2, like you've already noticed. I haven't tried newlib but since those sources are hidden somewhere in the woods it's IMHO better to fix the limitations in clib2.
For gcc 10 some 68k improvements and threading related patches had to go temporarily. But for OS4 and C++ <11 it should be alright. In other words, gcc 10 is still WIP. Gcc 9 has been merged in the main repo but I haven't yet opened a PR for 10 since I want to take a closer look at what I've done (and did not do) first since I will probably need help from Sebastian Bauer and it's a bit rude to ask for help without being atleast somewhat clear when trying to explain the problem :)
Quote:
Dare I ask if you are willing to deal with some issues later ?:)
I can always try. It's not my area of expertise though, and tomorrow the day job will absorb most of my time again.
This one needs it for one of the big games I want to make on os4, and it used very a lot in the game's code in all different ways, so fixing the game's code is pain. And it's better to have more things working in GCC, maybe someday someone will take a task of WebKit port, etc and those things will be in need.
I offer everyone 100$ for just fixing this one, but so far no one wants to deal with :)
Github won't let me comment on the issue so I will write my findings here for now (It keeps saying "You can't comment at this time."):
Looking at the code in gthr-amigaos-native.c the problem is that init_threadstore() has not been called yet so when __gthread_self() tries to obtain the semaphore &threadstore->sem it leads to a NULL pointer access.
A quick fix would probably be to add the line: __gthread_once (&threadstore_once, init_threadstore);
in __gthread_self() just after: __gthread_once (&libs_once, init_libs);
Same as how it is done in the __gthread_create() function.
I'm going to try building a fixed gcc 8 first, and if that works out then I will try to generate an updated patch and create a pull request to the sba1/adtools repo.
It works! At least the simple test case from the bug report for sure works: I have "before" and "after" words. Need a bit more tests, but the first 50$ of the promised donations done already :) Once we can be sure that all fine, will drop the second one. Thanks a bunch as always!
I tried it at 8.3.0
ps. That one needs to be in the adtools repo for sure!
It looks like we have c++17 and threading on gcc 9 now. But there seems to be a deployment problem left. As someone who has only done c++ on other platforms, I would expect my 'hello world' to be linked using just -lstdc++. But in this case that will lead to undefined references to __gthred_*. In the archive created by adtools there are thread model object files named gthr-amigaos-native and gthr-amigaos-single. If I link them as well everything works. But I must be missing something here?
Bah, you wrote it above kas1e: '-athread=native'. I should pay more attention :)
Well then, looks like it works. But you need to wait a bit more before it ends up in adtools together with salass00s fix. I need to integrate a minor fix in clib2 first.