SDK 54.16

@ChrisH

New stuff will always break backwards compatibility...

You can't support every bit from the past or you'll stop moving forward

@ChrisH
Quote:

It's just how it is on AmigaOS 4 today. The people who left are trying hard to make it as good as possible, but they can't deal with everything, document everything, and please everyone. There will be moments, nuts, and strange things, and we will all have to live with them and adapt or fix them as best we can.

-athread stuff It's an AmigaOS-4-specific switch, which wasn't documented, but that is how it is for now. There were plans to make it the default behavior, eliminating the need for this switch, but it never happened. But of course, it's open source; you can just fork adtools and make a pull request for necessary changes, and the next SDK will have them.

Quote:

Yep. So you can use gcc4.x if you have no need to use more modern compilers or an updated SDK. To have the same makefile now for both old and new GCC will require some makefile adaptation, which if you don't want to do, then stick with the old or new one instead.

And you should be aware that today's SDK is primarily the work of people who improve adtools, which are then packaged into the SDK. There is no longer a "large team of developers working on the SDK," so no "design decision" has been made. It's just the best way we can have it now. So, if you see something that needs to be improved, please contribute here: https://github.com/sba1/adtools. 

@ChrisH

This is the way I solved this problem in my Makefiles:



THREADFLAGS contains the needed flags if g++ major version is higher or equal to 8. And you can use THREADS_SUPPORTED for additional control.

@ChrisH
The only reason the GCC6 is included in the latest SDK is that it is the last one that supports SPE CPUs and is able to optimise code for it. By including it we set a base for anyone to have a compiler for this purpose. This was not available before in any package with an easy way to install it in any system.

About the -athread as much as I know it is like that for a lot of years and I thought that was some kind of standard. On the other hand, if I recall correctly, there was a discussion somewhere that this should be added at the default compilation flags, but some people objected because that would add an overhead even on applications that do not use it.

Now, you mentioned that it is not documented anywhere, and you are right about it. It only remains for this to be fixed. The best place would be wiki.amigaos.net. If you have access there you can add some information. If not, we can all create a page somewhere in an online shared doc and then I can upload it. Just let me know.

@walkero

Quote:
That's not entirely true. If you look at adtools.lha on OS4Depot, which contains GCC 8.3.0, you'll find in the share/info directory the file gcc.info, which has been edited to document the Amiga-specific alterations to GCC, including -athread. This information apparently never made it to any of the PDF versions of the GCC documentation.

@all

Please tell me when -athread gcc option is mandatory and when not.
Can you specify also what's overehead indroduced by this option and how it works?

A wiki description is usefull but it's also better to update SDK docs about this.
In SDK docs I expect to know all/most about amiga specific options.

@msteed
Thank you for mentioning this. Below is that part that has to do with -athread

Quote:

@flush
You will understand if this is needed by your app when you try to link the binaries and it complains like



Quote:
The same share/info folder exists in every SDK that has the above information, like msteed mentioned above.

Now, does that need a dedicated section in the introductory PDF file? Maybe yes. Maybe all the information should be in the wiki and some of that in this pdf file, but please let me know your opinion.

@George
If there is a plan for a quick "bug-fix" release for 54.16, then surely some bits can be changed or updated in the SDK's main PDF, and this -athread switch can be one of them.

But even if there is no plan for a fast-fix update, then it's probably still worth worrying about, even if -athread=native will be the default behavior, as it was planned, because the option will still be there and you can choose native (the default) behavior, or pthread, or single, etc. Overall, the option will not be removed on its own, so it is worth noting in the PDF even if -athread=native will be the default behavior.

@kas1e
There is no plan for a quick bug fix right now. Please correct me if I am wrong, but I haven't seen yet a major bug in the latest SDK that needs a fast fix.

@all
Everything we discussed so far are there for years. If something needs to change, like the -athread to be set as default, then I would suggest a pull request to adtools repo and if the maintainer accepts it, then it will be in the next SDK release. If you don't know how to do it, then open an issue at the repo asking for it. Maybe someone else would like to work on it.

If someone needs changes in documentation, provide it and I can upload it to the wiki (if you don't have access there). If needed to include it in the next SDK I can do it.

@walkero
Quote:

Aa far as i aware only some documentation changes, but nothing really hardcore which need quick-fix.

Quote:

:) Of course, I knew how to submit a pull request and how it works with adtools. All in all, I have already made a migration to the new binutils version, just wasn't commit it.

But to clarify, I am not talking about you or anyone else making changes to AdTools. I'm telling it like it is: Sebastian had plans to do so when I last spoke with him, but I don't know what his plans are now.

My point was specifically about the SDK's main PDF, i.e., if someday adtools will have -athread=native as the default behavior (it doesn't matter who or how made these changes in the repo); changes in the SDK's PDF still need it in any case to explain what athread is and for what, as this switch (default or not default, doesn't matter) will be there so users can choose the threading model.

So I only mention that the SDK's main PDF needs to be updated to mention the athread switch because it will be present, whether the default is -athread=native or nothing (as it is now). 

@kas1e
I agree with you and I apologise. The second and third paragraphs were not specifically for you but for everyone. I forgot to add "@all" before it, which I did now.

Quote:
In the best of situations, we might have a new SDK once per year. So, I wouldn't rely on the SDK PDF to find crucial information. In my opinion is more necessary for us to have the info at wiki.amigaos.net, because it can be updated by multiple people at any time.

@walkero

In OS4 SDK I expect to find all specific options related to AmigaOS4. The wiki page it's a plus and yes inside SDK an url can be pointed to wikipage to complete documentation.

It would nice to have also an update every six months with small/bix fixes and improvements like recompilation of GCC/VBCC with latest patches.

I'd like to see also more support for most used external libs, with a dedicated installer.

@flash
The OS4-specific options I believe are included in the SDK. If they are not easy to find, then this can be fixed in future releases, but they are there.

These days everyone is able to access the wiki and that should be the place where the latest and most updated documentation should be. The SDK has a snapshot of the documentation for the tools and an introduction to the SDK.

I don't know if you have seen it, but in the latest SDK, I added as much documentation as possible for most of the tools that are included. The wiki though is a continuous WIP which is able to get better and better with our contribution.

Now, maybe the perfect thing would be for someone to take parts of the wiki, write his own parts, and create a PDF file that has all the needed information, as you mentioned. This in my opinion would be great but it is also a huge project. It requires a deep knowledge of the operating system and how things are working under the hood. There are not so many people who could do such a thing and I haven't seen anyone interested in doing something like that.

I personally feel grateful that the wiki exists and that some people update it. And best of all, if something is missing we can add it.

I don't know if you guys have seen the video from the Devcon days at amiwest this year. We had a discussion about the new SDK and the documentation. At that discussion, I proposed that we can arrange a weekend to gather online together and work on updating parts of the documentation. We need to prepare of course and have coordination, but this is doable. Other communities do similar things and a lot of work is finished these days.

We can do something like that because, at the end of the day, the tools and the documentation we have is a matter of the community to make it better.

Quote:
I'd love that too but this means that a person would have to work on the SDK and the tools that need to be fixed and update all the time, like gcc, make, cmake, coreutils, libc etc. If there is someone to volunteer to do it that would be great.

Quote:
I actually have one for personal use. The thing is that if something is going to be released by someone has to have some minimum standards, i.e. that the libs are created for both clib2 and newlib, they pass all the tests that are possible to pass etc. To do that you have either to do it yourself for all these libraries, or the people who port them have to follow those standards. Again a big task to do, but if anyone would like to step up for it would be awesome.

@walkero Quote:
I don't think that overhead matters if you can't even compile trivial C++ programs.

Also, would -athread=single really add overhead? Seems like it's for single-threaded programs.

@walkero

Quote:

Would it be smart to just document that, what a developer hast to fulfill, to make as easy as possible for you to include it in the SDK. Including the test cases, because there might more than me that have no clue what actually a linked library an AmigaOS has to "support" be be best usable by other developers.

@MigthyMax
Quote:
I am not sure if things like that should end up in the SDK. What I would like to see is a tool that could be used to discover, download and install those libraries as soon as they are available. Maybe even update them if they are already installed.

In my opinion, the SDK is not the best place to have libraries, because of the frequency of the installation.

Quote:
The way the libraries should be created is documented in the introduction PDF that is included in the SDK. There you can find info on how to create static and dynamic libraries, as well as the release folder structure that should be followed. And those parts are there for years.

I believe that if we want to make a development environment as easy as possible for everyone it has to have standardisation in the libraries port, and by that I mean:
1. Follow all the rules that are documented in the SDK PDF and at the wiki
2. Provide the library for both newlib and clib2
3. Create it with all the necessary flags, like the -fPIC
4. Provide the source in a place where everyone is going to be able to have access to
5. Make sure that your port will pass all the tests that are possible.

Currently, we don't have that standardisation and everyone can distribute a library, even if it doesn't work properly. And the worst of all, some people do not even provide the changes that they did, although in some situations this is mandatory based on the library license.