I'm trying to build the GCC 11 cross-compiler from adtools, and am stuck. AFAIK, I've installed all the dependencies. However, it's failing with the following error:
crtbegin.c:59:15: note: while referencing ‘__DTOR_LIST__’
59 | static void (*__DTOR_LIST__[1]) (void) __attribute__(( used, section(".dtors"), aligned(sizeof(void (*)(void))) ));
| ^~~~~~~~~~~~~
Compiling crtend.c [lib.threadsafe]
Compiling crtend.c [lib.threadsafe/soft-float]
Compiling crtend.c [lib.threadsafe/small-data]
Compiling crtend.c [lib.threadsafe/baserel]
Compiling c.lib_rev.c [obj/libc]
Compiling ctype_isalnum.c [obj/libc]
In file included from ctype_headers.h:40,
from ctype_isalnum.c:35:
locale_headers.h:44:10: fatal error: libraries/locale.h: No such file or directory
44 | #include <libraries/locale.h>
| ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
Yes, the AmigaOS SDK has been successfully downloaded, and I saw the SDK being unarchived.
Ugh! The build finished, but only some of the tools are there (e.g., ppc-amigaos-addr2line, ppc-amigaos-ld). The actual compiles (ppc-amigaos-gcc & ppc-amigaos-g++) are missing.
Regarding the missing include from the SDK, this can happen if you have a broken lha installed in Ubuntu. All versions that come with Ubuntu do not work correctly.
This should be a working version, but you need to install it manually (download, ./configure, make install, ...): https://github.com/jca02266/lha
I've seen this before and can confirm this is caused by lhasa not being able to extract the .lha files properly when there are empty directories. As a side note, some files that used to be in base.lha are now in execsg_sdk .lha, in case anyone reading this couldn't find some files.
There are a number of options which may be of interest, but that - alone - will create for you the Xcompiler that you originally wanted.
The script will also tell you, before building, if you will have any unmet dependency packages - including - the lack of an LHA extractor that actually works.
In a nutshell, half of adtools_testing is a wrapper around adtools and the other half is a way to build tests / add tests ready for deployment on an AmigaOne.
Options to consider are things like using the alternative clib2 by afxgroup (e.g. ./adt -b -e beta10)
You also do not need to checkout coreutils unless you are actually interested in building them, or, you are trying to create a native version of the compiler package to transfer to an AmigaOne machine. Further, coreutils 8 needs to be fixed in ADTOOLS since it will not successfully build right now.
If liberty means anything at all, it means the right to tell people what they do not want to hear. George Orwell.
You also do not need to checkout coreutils unless you are actually interested in building them, or, you are trying to create a native version of the compiler package to transfer to an AmigaOne machine. Further, coreutils 8 needs to be fixed in ADTOOLS since it will not successfully build right now.
It would be nice if such things could be in the readme...
So, I need to switch back to coreutils 5? If coreutils isn't needed, then why would it interfere with building the cross-compiler? First, I had the missing SDK headers error (despite the SDK being unarc'd), then gcc and g++ don't get built after I executed: bin/gild checkout gnulib for-coreutils-8.27
You probably did not specify the "gcc-cross" target when invoking make. In that case, adtools assumes you want to build a cross compiler *and* a native compiler. The native compiler attempts to package everything up ready for an SDK release and so also uses coreutils.
If liberty means anything at all, it means the right to tell people what they do not want to hear. George Orwell.
Fine. I think Coreutils is a red-herring anyway. Your initial error is complaining during the build of clib2 due to the use of a subpar version of LHA.
In summary,
- Use a known working version of LHA and use adtools repo - or, use adtools_testing with ./adt -b - and know that coreutils 8 should not be used for now
If liberty means anything at all, it means the right to tell people what they do not want to hear. George Orwell.
Fine. I think Coreutils is a red-herring anyway. Your initial error is complaining during the build of clib2 due to the use of a subpar version of LHA.
I doubt that's the problem. I installed lhasa, as per the instructions in the adtools readme. I can also literally see it unarchiving the SDK's archives in the output printed to the terminal. The files were there.
However, the above doesn't matter, because that error went away after I executed: bin/gild checkout gnulib for-coreutils-8.27
After that, "make -C native-build gcc-cross" completed without error, but ppc-amigaos-gcc and ppc-amigaos-g++ were missing. At least, I didn't see an error at the time.
Quote:
- or, use adtools_testing with ./adt -b - and know that coreutils 8 should not be used for now
I'll try the last one first. Might need to delete everything and start from scratch.
@Hans The other thing you can do with my docker images is to run it, and by having a mounted volume, copy /opt/ppc-amigaos and /opt/sdk into your host machine and use them like if you had them compiled on your system. The docker images use Ubuntu, so it should be compatible.
I have now successfully built the GCC 11 cross-compiler. Thanks for your help.
Building GCC 5 failed, though, with compiler error such as:
adtools/gcc/repo/gcc/graphite-interchange.c:443:19: error: ‘isl_space_add_dims’ was not declared in this scope; did you mean ‘isl_set_add_dims’?
443 | isl_space *d2 = isl_space_add_dims (d1, isl_dim_in, n);
I tried building it because I need a compiler that still supports the P1022's SPE. Trying GCC 6 now...
... and GCC 6 is failing in a similar manner: code]graphite-isl-ast-to-gimple.c:2903:16: error: ‘isl_id_alloc’ was not declared in this scope; did you mean ‘isl_vec_alloc’? 2903 | isl_id *id = isl_id_alloc (isl_ast_build_get_ctx (build), "", for_info); | ^~~~~~~~~~~~ | isl_vec_alloc [/code]
Any idea on what broke? What do I have to do to make this work?
I've managed to get gcc 6 built too by using the SDK's clib2. The adtools project is suffering from a bit of bitrot, with things that used to work breaking.
Ideally we'd just use the latest GCC. Unfortunately, support for the SPE was deprecated in GCC 8, and removed in GCC 9. So, we need version GCC 7 or older.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
