gcc 9 and 10

@kas1e

Thanks, I'll send him a mail.

@sTix

i've created a new clib2 repository and i've started to remove some old stuff (i mean 68k one)

https://github.com/afxgroup/clib2/releases/tag/1.0

I've merged your math functions and i've added some new functions.
Not only. I've merged lunix and lnet into libc because the linking was a pain and is useless to create different lib since they are libc part.
Do you think we can work on a single project? or do you want to maintain the 68k stuff?

Hi, which version of adtools gcc implements posix threads via pthread library? My project is linked against newlib.

@SOVA
Quote:

Original posix based threading via pthreads even not enabled by default, and not fully implemented too. It miss some functions in our implementation like:

Quote:

So there is only native amigaos4 implementation of threading which has all the functions and for time being better to use that one.

You of course can still build that "native-posix-amigaos4" threading by compiling a single file from adtools and place it to the necessary place in your SDK, so once you will do -athread=pthread it will work, but it still will be lacking functions I list, and those ones always almost need it for any project.

@kas1e

Thanks for a prompt reply, Do I need special version of gcc to compile with pthread.h from OS4 SDK? Now I am using gcc 5.4.0 but compiler prints thread model: single. My project compiles and runs but I am afraid about impredictible behaviour.

@SOVA
If your project compiles and runs, it means it just uses pthread library, not that "c++ threading": they are 2 different things.


With C++ threading, if you have no support for it in GCC, your project will even not compiles.

In other words, if your code compiles and works, you have no needs to worry about c++ threading. The 5.4.0 version is ok too.

Currently, most of us use 8.4.0 and 10.1.0, but that for more or less "modern" code (for porting works for example, etc). But most of the stuff will work on 5.4.0 still.

@afxgroup

Great! I'm working on the complex.h parts now and after that's done many of kas1es namepace problems should go away. I'm slowly working backwards to give libstdc++ what it needs to be 100%. I started of in the other direction, stubbing everything in POSIX but that quickly got out of hand so I chucked everything out and started over, focusing on the things that we know we need, rather than going broad trying to implement things that we might need.

I definitely think we should try to integrate everything in the end. It shouldn't be to hard if we just follow the priciples of what's already there, keeping things small and self contained. But I think we should keep the 68k parts since the ideal IMO would be to integrate as much as possible in Olafs repo. I don't think we should be too OS4 centric, there's a lot to gain from sharing the burden and keeping it lean.

@sTix

Well OS3 has already ixemul and libnix that are far away from our clib2. that's why i prefer to concentrate the work to OS4. New kernel and exec is adding features that cannot be ported on OS3 that's why i prefer to remove code hard to maintain usning #ifdef everywhere.
However if you still prefer to maintain os3 code i'll get your changes and you can get mine if they are compatible with os3 too

@sTix
I see your pull request some changes about those "std::" fixes, but with clib2 fixes used your own fork of clib2. And just some obvious question: isn't it better firstly to pull request changes to clib2, so they will be in adtools, and then, pull request changes for adtools. So everything will be clean, in the same place as always, without too many forks.

@sTix,Afxgroup

As of now, it starts to be a bit messy: adtools have clib2, sTix have a fork of clib2, afxgroup have fork of clib2. That how some may think that all this "opensource" can cause a mess: it's very hard to agree on the same ideas of what and how and where should be changed. One wants to keep 68k, another one wants to remove it. One wants to make that kind of change, another one didn't. So then now 3 forks :(

Surely for developers, it may look better to choose newlib at this moment, because one, single version. But that mess with clib2 has a start to now lead us to nowhere :( Imho we need to agree and work on one single stuff and pull request it always to adtools, does not matter what we think.

So, my suggestion as a pure advanced user and sometimes do a little developing: clib2 changes should be in adtools. No forks! Only use forks for local work, and then pull request all stuff to adtool. Or it all will die in the half of way. Too many projects died because of forks. Let's annoy SBA till death so he will accept pull request, but not creating a fork which none will use later as they not in adtools.

@kas1e

Agree, but my PR in clib2 is 29 days old by now so I thought I might as well do a PR for adtools, then there's one fork less. SBA is very quick responding to PR:s.

About clib2, indeed me and afxgroup should work together IMHO. Once we get a clear yes / no from Barthel we can decide on how to proceed. If we get a no, then we can drop 68k and turn clib2 into an os4 lib only. If that's the case then we can drop my repo, or afxgroup:s (depending on what you want afxgroup, I don't have any emotional attachment to my repo , in fact I'd like to get rid of it).

We could also consider asking SBA to create a new repo under adtools. If we're going to drop 68k and do all sorts of funky things then at some point perhaps we should consider calling it something else to eliminate one source of confusion (and Barthel probably doesn't want to be tainted by our mistakes).

Before, and if, we do the last one, we should get Barthels opinion of course.

take a look at my repository and try the clib yourself. It has a lot of fixes (like shared objects and threads) plus a lot of other stuff that is missing in olaf clib2.
But i have changed file /gcc/repo/gcc/config/rs6000/amigaos.h in gcc to work in this way



But this code will not work with threadsafe version because i have to find a way to supports all clib2 variant. And however, for example, why we should have a ts version and one not? Is really useless imho

@afxgroup

Why? Please don't remove the 68k stuff and frankly, please don't branch it either. Send pull requests to Olaf if you want.

@NinjaCyborg

take a look at this

https://github.com/afxgroup/clib2/commits/master

Those are my changes in the clib2. A lot of stuff is not compatible with os3. Clib2 was stuck to 32bit files for example. Plus a lot of other things.
It is hard to maintain (for me) triple-quadruple code because the 68k and all its flavors.
If someone wants to add code from my version and add it to original clib2 can do this (and vice versa).

As i said os3 has ixemul. Does anyone tried that? Ixemul is the most compatible library os3 has. A lot of software use it. It is shared and posix compatible. No one (except maybe for Roadshow) use clib2 on os3. I didn't see any single piece of software that use clib2 on os3.
And however clib2 is there.. no one is deleting it. But if we need to port software from other platforms we need a fast, compatible, easy to maintain library.

If one day Hyperion will decide to open source newlib, well, even clib2 could be totally avoided but if we need fast fix, new implementations and mostly fast release we need to remove useless code.

@afxgroup

Please don't

Don't what? I don't understand?

@all

This is just wishfull thinking, i guess.

Would it be possible to enhance/add/change/compile gcc (and linker stuff) to make use of ExtMem on AmigaOS4?

That would workaround the platforms ram limitations a great deal (until we get 64bit memory access...hahahaha)

@Raziel

It's probably just the linker you're after. But no, I doubt anyone would dare to take on something like this. Even if it would be possible (in theory at least), it sounds extremely intrusive which would make it a nightmare to keep up with upstream. If you have a project this big, you probably have very long build times as well. In other words, a cross-compiler would be your best friend.

@sTix
Btw, do you have an interest in working on newer Binutils? Why I ask, is that I download Morphos's SDK source code, and there is not _that_ many changes in the diff file. Taking into account that we already have some version with specific amigaos4 changes + diff from morphos devs, it can be (i hope) a little bit easier?

And maybe after that, we can have at least working gdb (seeing patch sets from 5.3 version for os4, and changes in 8.3 version on morphos, it also didn't look like _that_ hard).

I currently rebuild GDB from https://sourceforge.net/p/adtools/code/HEAD/tree/trunk/gdb/ (as probably that is the latest one, as on SBA's GitHub I didn't see it anymore) over GCC 10.0.1, and it works. Through, of course, it still supports the only dwarf2, so no go for us anymore with newer versions of GCC, and dward4 was added somewhere in 7.5/7.5.1. And not sure what will be easier: add dwarf4 support to that GDB we had on source forge, or better made new port (7.5.1 or 8.3 or so). If go new port way, then we at beginning may have no needs for "sobj" debugging, disable everything, etc, just some basics. Then when necessary (and if) implement things. But GDB is must, it's too offten we can't go futher because of lacking this. And for that, we need newer binutils (as gdb need them, too).

I agree with kas1e. A working GDB is a must and if there is a way to have an updated working version that would be awesome.

@kas1e

Quote:

Yes, I'm slightly interested (and slightly relectant). IMO the major gaps right now is git (sgit seems to have halted?) and gdb.

Quote:

Aren't you mixing up coreutils and binutils (I do that myself all the time)?

Examining the MorphOS patches sounds like a good idea. I'll have a peek but I can't make any promises, to much going on here with work, kids not in school due to covid-19 and so on...