Provide clib4 as an additional C runtime library.

[3246251196]

As well as the existing newlib and clib2 as C runtime library choices, clib4 is now introduced. Support for clib4 is currently restricted to GCC version 11.

[3246251196]

It is not really possible for us to merge these changes into clib2. We need to be able to own our own clib repository so that we can make changes in a timely manor. A number of people are aware of the clib fork that Andrea has done and I think people will appreciate the ability to choose which C runtime library to use. I cannot really speak on behalf of Sodero/Andrea - other than to say the original work was forked from clib2 and a lot of functionality has since been added.

I am sorry, but I have no idea how to push a new branch to an existing PR.

[sba1]

Thanks for your contribution!

It is not really possible for us to merge these changes into clib2. We need to be able to own our own clib repository so that we can make changes in a timely manor. A number of people are aware of the clib fork that Andrea has done and I think people will appreciate the ability to choose which C runtime library to use. I cannot really speak on behalf of Sodero/Andrea - other than to say the original work was forked from clib2 and a lot of functionality has since been added.

I see that there is a need for a compiler with support for later features. I still hope that it is possible to have only one clib2 variant. @sodero @obarthel, @afxgroup. I even see some activity in the original repository.

I am sorry, but I have no idea how to push a new branch to an existing PR.

You don't need to push a new branch. You modify your old one (the one that you used to create the PR) and force push it.

[obarthel]

Thanks for your contribution!

It is not really possible for us to merge these changes into clib2. We need to be able to own our own clib repository so that we can make changes in a timely manor. A number of people are aware of the clib fork that Andrea has done and I think people will appreciate the ability to choose which C runtime library to use. I cannot really speak on behalf of Sodero/Andrea - other than to say the original work was forked from clib2 and a lot of functionality has since been added.

Since the layout of the clib2 fork changed considerably, merging the changes with the existing clib2 repository eventually crossed the point when the effort became a major challenge. I'm not proud of the original clib2 directory layout as it was in 2003, etc. but it made sense at the time, me being the only developer. The code was still managed in a subversion repository and only later wound up on GitHub.

I see that there is a need for a compiler with support for later features. I still hope that it is possible to have only one clib2 variant. @sodero @obarthel, @afxgroup. I even see some activity in the original repository.

These are the long lingering bug fixes and performance improvements which I finally managed to debug (including the slab allocator). They will (hopefully) get merged into the main branch of the adtools/clib2 repository.

The underlying public data structures and APIs of clib2 have not changed in what's currently in the development branch of the adtools/clib2 repository, which means that they are binary compatible and merely relinking the code with this version would be possible, not needing a full rebuild of the application linked against it.

I am curious if Sebastian's changes could also be merged back into the adtools/clib2 main branch. So far my main concern was in getting the 68k build repaired and improved, after all these years.

[3246251196]

How does one build a cross compiler using this repository for 68k? If that is possible, then I may need to make some changes to disable clib4 for any 68k build. Clib4 is only for os4.

I never tried building a cross compiler for 68k using this repository and I thought people used some other repo for that.

Thanks.

On Wed, 4 Oct 2023, 08:37 Olaf Barthel, @.***> wrote:

Thanks for your contribution!

It is not really possible for us to merge these changes into clib2. We need to be able to own our own clib repository so that we can make changes in a timely manor. A number of people are aware of the clib fork that Andrea has done and I think people will appreciate the ability to choose which C runtime library to use. I cannot really speak on behalf of Sodero/Andrea - other than to say the original work was forked from clib2 and a lot of functionality has since been added.

Since the layout of the clib2 fork changed considerably, merging the changes with the existing clib2 repository eventually crossed the point when the effort became a major challenge. I'm not proud of the original clib2 directory layout as it was in 2003, etc. but it made sense at the time, me being the only developer. The code was still managed in a subversion repository and only later wound up on GitHub.

I see that there is a need for a compiler with support for later features. I still hope that it is possible to have only one clib2 variant. @sodero https://github.com/sodero @obarthel https://github.com/obarthel, @afxgroup https://github.com/afxgroup. I even see some activity in the original repository.

These are the long lingering bug fixes and performance improvements which I finally managed to debug (including the slab allocator). They will (hopefully) get merged into the main branch of the adtools/clib2 repository.

The underlying public data structures and APIs of clib2 have not changed in what's currently in the development branch of the adtools/clib2 repository, which means that they are binary compatible and merely relinking the code with this version would be possible, not needing a full rebuild of the application linked against it.

I am curious if Sebastian's changes could also be merged back into the adtools/clib2 main branch. So far my main concern was in getting the 68k build repaired and improved, after all these years.

— Reply to this email directly, view it on GitHub https://github.com/sba1/adtools/pull/148#issuecomment-1746307102, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNDARPFOQMQZ7S5DLQVAOTX5UG25AVCNFSM6AAAAAA5PJNK7SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBWGMYDOMJQGI . You are receiving this because you authored the thread.Message ID: @.***>

[obarthel]

How does one build a cross compiler using this repository for 68k?

I am using it for native 68k compilation only, e.g. for my old Samba port and even the tools which ship with Roadshow that cannot be built with anything but gcc. No idea how well it will work with AmigaOS4 because I am without a working cross-compiler for it.

My 68k native gcc 2.95.3 (plus binutils) was bootstrapped/migrated one step at a time to eventually build itself with clib2, shedding all ixemul.library dependencies in the process. It gets the job done, although I wish I could just relink the binaries against the most recent developer branch clib2 for 68k. This is exceptionally difficult because the compiler will eventually decide to rebuild itself from scratch, breaking itself by accident.

As a rule, I avoid cross compilation because I found it to be surprisingly brittle and complex at the same time, which means, for example, that I haven't been able to build a Mac-hosted cross-compiler for AmigaOS4 for more than 10 years :-( No luck with the Linux build either, and I've tried again and again, eventually gave up. Any help to get this working again would be welcome!

[3246251196]

Thanks. I just wonder if this repository is meant to be able to handle also building a 68k cross compiler for version 11. I get the feeling that people generally use this to build for ppc.

I am not even sure if anyone has tried to build a gcc 11 xgcc for 68k in a long time and whether it works at all for gcc 11.

The readme says that 68k is not in good shape, so perhaps any potential breaks are acceptable. But we should probably say that 68k is just not supported in this repo. Presumably if you are using gcc 2, you are not using this repo since gild cannot even handle version 2 of gcc.

On Wed, 4 Oct 2023, 10:48 Olaf Barthel, @.***> wrote:

How does one build a cross compiler using this repository for 68k?

I am using it for native 68k compilation only, e.g. for my old Samba port and even the tools which ship with Roadshow that cannot be built with anything but gcc. No idea how well it will work with AmigaOS4 because I am without a working cross-compiler for it.

My 68k native gcc 2.95.3 (plus binutils) was bootstrapped/migrated one step at a time to eventually build itself with clib2, shedding all ixemul.library dependencies in the process. It gets the job done, although I wish I could just relink the binaries against the most recent developer branch clib2 for 68k. This is exceptionally difficult because the compiler will eventually decide to rebuild itself from scratch, breaking itself by accident.

As a rule, I avoid cross compilation because I found it to be surprisingly brittle and complex at the same time, which means, for example, that I haven't been able to build a Mac-hosted cross-compiler for AmigaOS4 for more than 10 years :-( No luck with the Linux build either, and I've tried again and again, eventually gave up. Any help to get this working again would be welcome!

— Reply to this email directly, view it on GitHub https://github.com/sba1/adtools/pull/148#issuecomment-1746523356, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNDARNM7S24GH7YAP3GFSTX5UWGJAVCNFSM6AAAAAA5PJNK7SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBWGUZDGMZVGY . You are receiving this because you authored the thread.Message ID: @.***>