Probably will be far better and more easy (at least for begining) to deal with little issues like those ones:

https://github.com/sba1/adtools/issues/86
https://github.com/sba1/adtools/issues/79
https://github.com/sba1/adtools/issues/63
https://github.com/sba1/adtools/issues/59
https://github.com/sba1/adtools/issues/58
https://github.com/sba1/adtools/issues/57

Half of them are "something is not a member of std" and probably can be fixed on the compiler build times.

@IamSONIC

Quote:

Unfortunately I have more time consuming hobbies than time :)

One big problem though, is that it looks like an endless pit of work. But it probably isn't if we can chop it up into pieces and distribute the work. If we'd 'just' start stubbing things to get it to build, then we'd have a list of gaps that we can work with, setting priorities, estimating effort (and perhaps creating bounties based on that) and so on. This might be a big task in itself of course.

@kas1e

That's a good list. That's the type of very specific info I was trying to describe in my last post. I missed your comment.

@sTix
Or for example this one:

https://github.com/sba1/adtools/issues/92

That one works for clib2, but not for newlib, which means it just some mess with includes or something of that sort.

@sTix
Hello there. I tried to compile gcc 10 for using with cross compiling, and I had the following errors



I used g++-10 to compile it on Linux, and the following commands.


Thanks for the help

@walkero

Are you using *both* the compiler and clib2 from below?

https://github.com/sodero/adtools/releases/tag/alpha-2

It's important that you're not using your old clib2. ENOTSUP is not defined in that one.

@walkero
Don't you forget before to change the SDK link on the newer one in /amiga/adtools/native-build/makefile ? Because I doing it exactly as you say, just with of course changed the link to SDK.

Also, you may try first to not use -j4 , until it downloads and unpacks SDK, and then break the process and restart with -j4.

@walkero

Sorry, I did not read your post properly. This shouldn't happen.

If you lookup CLIB2_URL and CLIB2_SHA1 in native-build/makefile, what does it say?

@sTix
May I ask you if you still worry about, to enable for further tests "pthread" threading as well ?

Currently, we have only "AmigaOS-native" threading enabled (that is this gthr-amigaos-native.c, from the amiga-native-thread patch), but there is also gthr-amigaos-posix.c , so to have POSIX based threading works (via pthreads).

As Sebastian says a year ago, the pthread wrapper is already there, but not bundled yet. This is that gthr-amigaos-posix.c


Currently if we just trying to compile with -athread=pthread, we have "ppc-amigaos/bin/ld: cannot find gthr-amigaos-pthread.o: No such file or directory".


So to have it bundled we need to fix 2 issues:

1). file gthr-amigaos-posix.c didn't compiles at all and didn't placed to the /usr/local/amiga/lib/gcc/ppc-amigaos/10.1.0/ directory.

So we need to add it adtools build process (like done for qthr-amigaos-native.c).

2). even if we compile it and place when amigaos-native one placed, then when we choose "-athread=pthread", it asks for gthr-amigaos-pthread.o, and not gthr-amigaos-posix.o (see name clash pthread vs posix).

In other words, all we need to do is copy the way how gthr-amigaos-native file is compiled/placed, and or name on compiling-object stage it as gthr-amigaos-pthread.o, or, change -athread=pthread option to -athread=posix option and keep the name of original c file and of an object the same.

I already can compile that gthr-amigaos-posix.c to gthr-amigaos-pthread.o and use it with -athread=pthread, but will be fine to bundle it by default so it can be futher bug-tracked and improved too


PS. It was discussed here a bit: https://github.com/sba1/adtools/issues/64

@kas1e

Right now I'm digging into the problems with things not being exposed in the 'std' namespace. I'd also like to get a good picture of the gaps in clib2. This will probably take some time so I don't want to make any promises, but if no one does it in the meantime I can have a look.

@sTix
At least all the std:: issues I reported, all of them implemented and works when I just remove std::. So chances high it just some configuring issues.

Thank you guys for your replies

@sTix
Quote:

You were right. I was using the wrong CLIB inside makefile. Now it compiles just fine. Thanks a lot.

@kas1e
About the AmigaOS 4 SDK, yeah. I have a fix before I compile gcc that downloads the right SDK 53.30

For your info, I created new docker images that have the gcc 8 and 9 from sba1 repo and gcc 10 from sodero repo already compiled, if anyone wants to use them on cross compiler development environment.

They can be found at
https://hub.docker.com/repository/docker/walkero/amigagccondocker

@walkero

Nice, thanks!

Unfortunately -fanalyzer doesn't work locally (at least for ScummVM)

I get my memory filled up by it pretty early on when compiling commandLine.cpp.
It grows to 77% filled and then ccplus11 errors with a "cannot allocate 104 bytes".

Switched it off again, too bad

@Raziel

That's a shame. I can imagine doing static analysis on something that big requires a lot of memory.

@sTix

Yes, i really hppe that gcc can be changed to use ExtMem once it has been introduced to the public (it's still in beta, right?)

That would solve a bunch of problems for me

@sTix
Maybe you can do a pull-request will the latest gcc9 and gcc10 you had in your branches to the original adtools repo? I am already on gcc10 for some time, it surely not worse than gcc8.x for us. And having it in adtools repo will help everyone to not mess between different repos.

@kas1e

Yes, I intend to do this as soon as this one is merged (it's needed to enable C++17): https://github.com/adtools/clib2/pull/13

Otherwise we need to use my clib2 fork in adtools and that's not great either

Don't know if Barthel is active on Github, it's taking too long I think.

@sTix
Olaf answer very fast if you drop him a mail, check PM for mail