AROS-20211128-DC01-any-i386-contrib:

LunaPaint = Old Version (Miker's version is more up-to-date)
MystiCube = Does not work
DTConvert = Don't convert anything (Miker's version works fine)
FryingPan = GURU
PlayMF = GURU
Regina= How to install on AROS x86?
Regina= arexx_tests do not work, if I use RX as a tool I get a GURU

Fully integrating Contrib takes a lot of time to check every single file. Wouldn't it be more useful to publish updates separately to speed things up!

I have integrated almost all the contrib on AROS one, tomorrow I will check for other problems.

@AMIGASYSTEM

Thanks for the tests. I understand the integration takes a lot of time - I do some tests on my side before each release as well.

What I will do is that I will publish a separate change log for contrib to give people better visibility at what has changed. With regards to builds, the first build (like this one) as well as the final release will always be "full". In between I will try to provide just changed components where possible to speed things up.

I took and note at Regina problem you reported and will look at it.

deadwood, as happened in the past "contrib.tar.bz2" if unpacked on Windows with WinRAR or 7zip, generates "strange" corruptions.

For example GCC, if you try to compile the "IconClone source by Miker" 2 times or more, it generates "always different" GURUs see screenshot ! if you try to recompile with the same name the system crashes.

On the other hand, if I unpack "contrib.tar.bz2" on AROS, the GCC "seems" not to generate any GURUs, tried to compile a dozen times without any problems.

In my opinion it's the "TAR" that is not handled well on Windows, I haven't tried it on Linux, someone should try.

I attach 3 Screenshots of GCC and IconClone Source

I haven't had any corruptions with 7zip

It's possible that WinRAR or 7Zip might not be handling tar.gz correctly. Your alternative is to install unix environment for Windows (I believe it's called MInGW?) and then use linux versions of tar. Also if you suspect problem with unpacking, use some soft of checksum program (sha256sum on Linux) to check the checksums of "non-working" GCC and "working" GCC.

Please also note that default start in Shell is way too small to run GCC. The errors you are getting suggest memory corruption which often happens when stack is too small.

As you know I don't use Linux, I will continue to unpack TAR on native AROS which guarantees me compatibility anyway, I will also try unpacking TAR archives on OS3 (AFA OS) on WinUAE which should provide good compatibility.

Regarding the Shell, the GCC "unpacked on AROS" as said seems to have no Stack problem, I will do more Tests.

Is there a different way on AROS to run GCC besides the Shell?

No, gcc is a command-line application. You either needs to run it from AROS Shell or from "sh" (Linux shell that is ported to AROS)

Sorry deadwood one more question, I have noticed every time a new contrib comes out, the size of the binary files always changes, even though the version is always the same.

I suppose this is motivated by the different version of the compiler.

I ask this because I would like to understand if I have to overwrite/update these binaries even if they have the same version, or nothing changes if I don't update them, thanks.

Are you asking about any specific binary or binaries in contrib in general?

Practically almost all of them, as an example you can see in the screenshot some files for comparison (both work fine), same versions but belonging to a different contributor

Ok, I understand.

There is no simple answer. First, I think the size change of a few bytes is not something that can indicate change. If the size changes more than 10%, there it can be a sort of an indicator. Secondly, if often happens that a fix is made but a version is not update - so just looking at version numbers will make you miss changes.

One place of reference for you can be my change log that I mentioned in previous post. Then if you have a suspicion that something changed but is not included my the change log, you can check the history. Here for example is history of dopus from contrib:

https://github.com/deadw00d/contrib/commits/master/dopus

Looking at dates of commits and ranges for the release you can confirm whether something has been changed.

In general also keep in mind that there is a rather small number of commits happening in contrib, so don't expect more than a few changed software each release.

OK thanks for the info, that's what I had thought, at this point it's less time consuming to overwrite everything, what I was worried about is that the different size could include corruption, given the 'dubious' incompatibility of TAR on Windows, to be on the safe side I'll continue to unpack the TAR Archives on AROS.

In any case, even a decimal version change would be important and would facilitate updates by users.

I didn't quite understand about gcc however the version before this one from dopus5 works the latest one doesn't, i.e. if I open a shell instance from the directory panel

No the previous version many binaries were compiled 'non-executable', this new one corrected and works well, with some more complex sources the Stack needs to be increased.

yes I did not compile anything I thought it would work since the instruments are recognised

With the old version, a parameter had to be added to compile some binaries, now with the new one the problem has been corrected.

What problems have you encountered with the new version?

To translate into English, use deepl.com, which is the absolute best!

if I install the new tools they are not recognised by the system the old ones are

I don't understand, what does 'unrecognised' mean?

from shell but only button from directory panel, use dopus5

the old development tool works if open shell button from dopus5 panel, the new tool do not works