gcc 9 and 10

Quote:
It can be a bit confusing to patch patches and work with two repos at the same time (the adtools repo and the submodule in binutils/repo). But it's a pretty nice setup. Once you've done gild checkout binutils you can start working on the binutils/repo. After the checkout that repo will be in the middle of a merge session. You'll need to fix all conflicts and run git am --continue, then you'll get new conflicts, fix them, repeat until all conflicts are gone. If you look in the commit history when you're done, you'll see that all patches are there as separate commits. If you need to fix additional things after all patches are applied, just create a new commit. When the binutils repo is in good shape, run genpatch to regenerate the patches. If you did additional commits, patches for those will be created in the patches dir belonging to your new binutils version. Then you need to create a commit in the adtools repo containing all the new patches. That's the commit you make a PR out of.

Quote:
Yes, I see no reason to keep them.

Quote:
I don't think we should hide warnings with CFLAGS. They might be valuable and fixing them isn't much work.

Quote:
There are some documentation fixes if I remember correctly and I think those are nice to have. Ideally it should be possible build a reasonably polished SDK from adtools IMO. I think we can skip 68k, it will still be possible to build older versions with 68k support using adtools. If we want up to date 68k support in adtools we should look into bebbos work anyway.

These are just my opinions though. Sebastian has the final word. Creating a PR is a good way of getting feedback :)

@sTix
Wrote you mail about all that git issues to clear up some things.

Anyway, I also tried to patch Binutils 2.29.1 (that one where dwarf-5 were added), and this one is a little bit more different than just 2.24: elf32-ppc.c (which is mostly a full copy for our elf32-amigaos.c with some changes) were changed more, functions names, the functions itself, etc. So that will need some additional (but still not hard one IMHO) work.

But i think we better move version by version of the course as you say, as we will fix things step by step, and that will be surely easy.

I also wrote a mail to Sebastian, asking if he ok with removing, for now, morphos/amithlon from patches as they of now use anymore by anyone in morphos, and amithlon is amithlon.

Yes 2.24 to 2.29 is a big step. Not much inflation in binutils land. They've only reached major version 2 in 30 years :)

Can you forward the mail to rolfkopman <snake like a> gmail <dot> com?

@sTix
Mail sent.

ps. received a mail from Sebastian, he says that he of course agreed to remove Amithlon and Morphos, as while adtools were started years ago as cross-platform for everyone, today that isn't the case anymore, so we can concentrate on os4 stuff. Now I just need to get familiar with all that gild patching mechanic and can make a proper 2.24 replace

@kas1e

FYI: I bumped gcc to the latest release, 11.3.0 (pending PR and test build).

@sTix

Quick test with ScummVM shows it's working (no full build yet due to ScummVM source bugs).

Thanks a lot

@sTix
Has gcc 12 been released beyond the base release?

C++ is nearing 2023 release so gnu/gcc might wait for that to release 12.1 ?!

@Raziel

Nice!

@trgswe

It looks like it will take a couple of months before gcc 12 is released: https://gcc.gnu.org/develop.html#timeline

@sTix
found gcc 12 at https://gcc.gnu.org/gcc-12/changes.html
do note that there are changes especially for PPC, some C++-23 additions, and C2X additions, supports two new debug formats CTF (should be smaller, faster etc.) and BTF (only for linux kernel), anazlyzer got a workover, removed some bugs in c++ and libstdc++.

It should have been released in april, it is now at stage 4, so it most likely is tied to C++-23 for release of 12.1.

@kas1e

Quote:

That patch only fixes syntax errors in the 'texi' files, provided by the Port for documenting
the support for the hunk object file format. thus can be ignored if going for a OS4 only target
binutils. Even the added amiga.texi amigalink.texi files can be omitted, like the modification
on other texi files.

BTW you could check these files, if you generate the documentation, which as long i know isn't auto,
automatically generated during an 'make install' call.