sba1
Find a way to package the new GCC 8 for debian/amd64
Please find a way to build a cross for debian/amd64. Building and shipping a working GCC 8 requires a fixed Clib2 but that in turn requires that Clib2 files from the SDK to be overwritten.
I see two possibilities:
-
We bundle the clib2 products with the compiler. Producing the compiler would be similar to the way the non-package build works (i.e., first xgcc is compiled, then clib2, then the full-fledged toolchain) then.
-
We bundle the the clib2 products in the sdk package or in a dedicated package. This would probably be nicer but it probably means that the steps that produce xgcc needs to be duplicated.
If you're close to the build quota on Travis, wouldn't n.2 be worse ? Then I'd go for n.1 In both cases what must be fixed is the sdk installer script, that should avoid overwriting the modified clib2 with the one from the SDK (depending on which is installed first too, modified clib2 or original SDK).
I chose the 2nd variant, there is now a fourth package called adtools-clib2 that depend on the adtools-sdk package. No care is taken to avoid files to be overwritten. It is not finished yet.
I disabled the native build for travis in the meantime, to get some time (the native binaries are produced using another way currently).
Understood. In the meantime, I've done like you said, taken the latest clib2 archive from bintray and simply overwrote the existing clib2 directory. I can't compile anything using bool, because in stdbool there's: #define bool _Bool
but nowhere else a typedef or define for "_Bool".
Should create a separate ticket ?
Am 2018-06-18 10:15, schrieb AV00:
Understood. In the meantime, I've done like you said, taken the latest clib2 archive from bintray and simply overwrote the existing clib2 directory. I can't compile anything using bool, because in stdbool there's: #define bool _Bool
but nowhere else a typedef or define for "_Bool".
Libstdc++ features highly depend on the clib2. So unless the libstdc++ that you have is compiled using the same clib2 I have my doubts that it will work. That is, the clib2 files need to be replaced before the libstc++ is being built. This is the case now for the standard packaging. The travis build however currently fails do these packages are not available yet.
I wish I could reach linking stage, it bombs much earlier, at compilation.
I've dug the issue deeper and there is a conflict with stdbool.h, there's one in Clib2 and one for the compiler itself in /usr/lib/gcc/ppc-amigaos/
I'm not sure if I understood your procedure correctly. But some header files of libstdc++ include some generated header files and these depend on the availability of certain features of the clib2 that are determined at compile time of libstc++. Replacing only clib2 is therefore unlikely to work.
What you could do is to replace all files (clib2 but also libstc++ from the main archive) with the contents of the native archive. This could work but I haven't tried it. Or you have to build libstdc++ yourself (which is equivalent to building gcc yourself).
If you are eager, you could also try to generate the Debian packages or simply follow the instruction in ReadMe.md how to create a non-packaged gcc.
On 2018-06-18 23:18, Sebastian Bauer wrote:
I'm not sure if I understood your procedure correctly. But some header files of libstdc++ include some generated header files and these depend on the availability of certain features of the clib2 that are determined at compile time of libstc++. Replacing only clib2 is therefore unlikely to work.
What I'm saying is that there are TWO stdbool.h includes that gets installed, one from the adtools-gcc package, the other coming from Clib2. And the latter has precedence and breaks including a C header file within a C++ project. See here: nat@bigD:~$ dpkg -S /usr/lib/gcc/ppc-amigaos/5.5.0/include/stdbool.h adtools-gcc: /usr/lib/gcc/ppc-amigaos/5.5.0/include/stdbool.h (Belongs to adtools-gcc)
and of course there is stdbool.h in: /usr/ppc-amigaos/SDK/clib2/include/stdbool.h
With newlib, there's no problem as it doesn't have its own flavor of stdbool.h
Regarding your idea of replace all files with the content of the native archive, it's what I've done but std::to_string() and others are missing.
If you are eager, you could also try to generate the Debian packages or simply follow the instruction in ReadMe.md how to create a non-packaged gcc.
I wish I could just install it and have it work with C++, like it is with newlib already.
Am 2018-06-19 09:23, schrieb AV00:
On 2018-06-18 23:18, Sebastian Bauer wrote:
I'm not sure if I understood your procedure correctly. But some header files of libstdc++ include some generated header files and these depend on the availability of certain features of the clib2 that are determined at compile time of libstc++. Replacing only clib2 is therefore unlikely to work.
What I'm saying is that there are TWO stdbool.h includes that gets installed, one from the adtools-gcc package, the other coming from Clib2. And the latter has precedence and breaks including a C header file within a C++ project. See here: nat@bigD:~$ dpkg -S /usr/lib/gcc/ppc-amigaos/5.5.0/include/stdbool.h adtools-gcc: /usr/lib/gcc/ppc-amigaos/5.5.0/include/stdbool.h (Belongs to adtools-gcc)
But this is about gcc 8, isn't it? ;) In gcc 8, the compiler includes have precedence over the clib ones. This usually works better, because the the capabilities of the clib2 are queried at compile-time of libstdc++.
But gcc 5 is basically not supported anymore and I don't plan to backport the changes. Relevant changes will be backported only to gcc 6 (and later gcc 7, because this is the last one that supports the SPE unit of the P1020 directly). But for now, gcc 8 and clib2 is the most stable thing you can get with regard to C++ support (even better than with newlib). Mixing stuff will not work.
I wish I could just install it and have it work with C++, like it is with newlib already.
Some people are already using gcc 8 and are reporting that some stuff works and some stuff doesn't work. I'm especially interested in the latter.
Suggestion if you want to help gcc 8 development: Follow the instruction in the ReadMe.md (just two or three steps, but exchange 5 or 6 with 8) or help to complete the packaging more quickly if you really need that. You could also wait for me finishing the packaging, but it simply will take a while for me to finish it.
On 2018-06-19 10:07, Sebastian Bauer wrote:
nat@bigD:~$ dpkg -S /usr/lib/gcc/ppc-amigaos/5.5.0/include/stdbool.h adtools-gcc: /usr/lib/gcc/ppc-amigaos/5.5.0/include/stdbool.h (Belongs to adtools-gcc)
But this is about gcc 8, isn't it? ;) In gcc 8, the compiler includes have precedence over the clib ones. This usually works better, because the the capabilities of the clib2 are queried at compile-time of libstdc++.
The only reason I'm still using 5 is because there's not a debian package yet. :-D
But I've tried native with the new clib2 over the weekend and I got the same error for missing std::to_string() .
But gcc 5 is basically not supported anymore and I don't plan to backport the changes. Relevant changes will be backported only to gcc 6 (and later gcc 7, because this is the last one that supports the SPE unit of the P1020 directly). But for now, gcc 8 and clib2 is the most stable thing you can get with regard to C++ support (even better than with newlib). Mixing stuff will not work.
I did mix stuff (new clib2 with old gcc5) only because I didn't have any other mean of trying the "fixed" clib2.
Some people are already using gcc 8 and are reporting that some stuff works and some stuff doesn't work. I'm especially interested in the latter.
Suggestion if you want to help gcc 8 development: Follow the instruction in the ReadMe.md (just two or three steps, but exchange 5 or 6 with 8)
or help to complete the packaging more quickly if you really need that.
I'm not a debian package expert, unfortunately.
You could also wait for me finishing the packaging, but it simply will take a while for me to finish it.
I'll wait for a bit, then try to compile it myself. I just don't like overwriting too much of existing debian packages.
On 2018-06-19 10:07, Sebastian Bauer wrote:
Suggestion if you want to help gcc 8 development: Follow the instruction in the ReadMe.md (just two or three steps, but exchange 5 or 6 with 8) or help to complete the packaging more quickly if you really need that.
I'm trying that and compilation fails several times in binutils because of -Werror and mainly case statements with fall-throughs.
Am 2018-06-19 17:54, schrieb AV00:
I'm trying that and compilation fails several times in binutils because of -Werror and mainly case statements with fall-throughs.
I fixed those problems for the native build (that also uses gcc 8), but maybe some other are still there that are needed for cross builds.
See https://github.com/sba1/adtools/blob/master/binutils/2.23.2/patches/0010-Fix-Wimplicit-fallthrough-warnings.patch
At least the native binutils goes through with these changes with gcc 8.
You are welcome to fix the remaining problems if there are any in a similar fashion. I haven't a host gcc 8 installed on my system yet.
On 2018-06-19 21:27, Sebastian Bauer wrote:
I fixed those problems for the native build (that also uses gcc 8), but maybe some other are still there that are needed for cross builds.
See https://github.com/sba1/adtools/blob/master/binutils/2.23.2/patches/0010-Fix-Wimplicit-fallthrough-warnings.patch
At least the native binutils goes through with these changes with gcc 8.
Even other patches don't get applied, I managed to get it to compile and build, but the resulting executables are missing references to __gthread_getspecific() , which should have been compiled in as part of the athread model but aren't.
You are welcome to fix the remaining problems if there are any in a similar fashion. I haven't a host gcc 8 installed on my system yet.
Similar fashion ? I haven't find a way to fix them, I only mangled the Makefile so not to have -Werror stop everything but I have no idea why the patches don't get applied. Or rather, I could see on the command line that they were applied but somehow, possibly because of the different build tree, these patches aren't in effect.