In the PSPSDK (Homebrew) we are using the Binutils 2.16.1 to assemble and link the code for the PlayStation Portable, however that release is getting quite outdated (3 versions have superseded it). The community and me have been updating the GCC and newlib to the latest stable versions and everything seems to work with the old binutils.
Will GCC produce better code with binutils 2.19? Why?
Will binutils 2.19 produce better elf files and libs than 2.16.1? Why?
binutils 2.19 has a new ELF linker called gold which is multi-threaded, written in modern C++, and quite a bit faster than the usual ld linker. I'm not sure however about the work involved to adapt it.
Other than that, well new versions always are a good idea. Performance and bug fixes are likely to have been included, of course. I think i would certainly try it and if something goes wrong you can still backstep.
In general, you don't need to upgrade binutils unless you run into some bug fixed in a later binutils version, or need new features (such as linker build-ids).
In particular, GCC code generation is largely independent of binutils (except for constructs like __thread, which require certain level of support from binutils).
Related
I have to compile 3 versions of gcc, say 9, 10 and 11.
My system gcc is version 8 (let's say).
Question : do I have any advantage on compiling gcc-v9 with gcc-v8, gcc-10 with gcc-v9 and gcc-v11 with gcc-v10 ?
Or I don't have any advantage and I can compile them all the gcc-v8 ?
Thank you for pointing out some directions for further research.
GCC has a "bootstrap" build process. So when you try to build gcc-11 with only gcc-8 installed, it will build a temporary "stage 1" version of gcc-11 using gcc-8, then compile gcc-11 again using gcc-11-stage1. Thus no matter what you start with, the version of gcc-11 that comes out of the build process was effectively compiled with itself.
So all that matters is that gcc-8, or whatever "system compiler" was previously installed, is able to build a stage1 version of gcc-11 that runs well enough to compile the stage 2 version. It doesn't matter whether your system compiler is good at optimizing, and gcc's source code is deliberately written to use a fairly minimal set of language feature (at least for stage 1), so you are not likely to run into trouble with your system compiler having missing or buggy support for obscure corners of the language. Historically, the "system compiler" was often not gcc at all, but some compiler provided by the computer vendor or an unrelated third party, and so one couldn't rely much on its quality; gcc was designed with that in mind.
Theoretically your system compiler could have a bug which miscompiles gcc-11-stage1 in such a way that it appears to work, but itself miscompiles stage2. This is unlikely, and it's even less likely that it would happen in a way that wasn't obvious (e.g. the stage2 compiler simply segfaulting). If worried, there's an option to have stage2 build a stage3 compiler, and then check that both versions are identical. So as long as the build completes, you can be pretty confident that the final installed compiler is fine and unaffected by bugs in the original system compiler. (All that said, a reference to Ken Thompson's "Reflections on Trusting Trust" is obligatory here.)
So in practice, you don't need to worry about the version of gcc used to build a new version. Whatever you happen to have installed already, within reason, will be fine.
How to switch this example here to use gcc?:
https://github.com/googlesamples/android-ndk/tree/master/other-builds/ndkbuild/hello-libs
Is there a way to set this over the gradle files?
As of the latest ndk(18), gcc is no longer supported and you are forced to use clang.
I faced some problems switching to clang and I am considering switching to cmake as it is recommended.
About the argument that gcc is better
gcc produces more optimized binaries than clang in android NDK
while there is some truth to this, there seems to be a lot of discussion on this topic that it is because of the gcc implicitly using -Bisymbolic which is bad. You can find in depth conversation on ndk github repo here
https://github.com/android-ndk/ndk/issues/495
Its quite long, but very insightful.
How I can to know what is a minimal version of glibc for gcc or binutils?
Regards.
binutils doesn't generally have a minimal glibc requirement because it doesn't have too much glibc-specific details in it. it's merely a collection of low level tools like an assembler and linker and objdumper all of which are built on code included in binutils.
gcc is a different beast -- it needs to know intimate details about C library capabilities. in the specific version of gcc you have, consult the INSTALL/index.html file (and particularly, the Prerequisites page) for the requirements.
On the SourceForge page for MinGW, you can download the GCC 4.5.2 and that's the latest version. On the GNU mirrors, you can download the GCC 4.6 source and compile it with one of the possible windows targets:
i[3456789]86-w64-mingw*
i[3456789]86-*-mingw*
x86_64-*-mingw*
Is there a difference between using one of these targets and the traditional GCC for MinGW? Would it make sense to use the regular GCC because it has more up-to-date versions or would it make more sense to wait until an up-to-date GCC for MinGW is released?
As you can see in the README file accompanying the MinGW release of GCC on SourceForge, no local patches were used, and I think this has been the case for quite a while now, so assuming there were no changes in the GCC codebase that require new local patches, you can very well download the GCC sources from one of the mirrors and build them yourself.
I have done so myself in the past, especially because I use gfortran, which is under quite heavy development, so from time to time I take the most recent snapshot and build that myself, so I can use certain new features that were only recently introduced.
(I have to admit that it took some trying to get the build to run without errors, and after a period without problems, I recently ran into some new ones that I couldn't completely smooth out. I will have to try again soon.)
This question must apply to so few people...
I am busy mrigrating my ARM C project from Winarm GCC 4.1.2 to Yagarto GCC 4.3.3.
I did not expect any differences and both compile my project happily using the same makefile and .ld files.
However while the Winarm version runs the Yagarto version doesn't. The processor is an Atmel AT91SAM7S.
Any ideas on where to look would be most welcome. i am thinking that my assumption that a makefile is a makefile is incorrect or that the .ld file for Winarm is not applicable to Yagarto.
Since they are both GCC toolchains and presumably use the same linker they must surely be compatable.
TIA
Ends.
I agree that the gcc's and the other binaries (ld) should be the same or close enough for you not to notice the differences. but the startup code whether it is your or theirs, and the C library can make a big difference. Enough to make the difference between success and failure when trying to use the same source and linker script. Now if this is 100% your code, no libraries or any other files being used from WinARM or Yagarto then this doesnt make much sense. 3.x.x to 4.x.x yes I had to re-spin my linker scripts, but 4.1.x to 4.3.x I dont remember having problems there.
It could also be a subtle difference in compiler behavior: code generation does change from gcc release to gcc release, and if your code contains pieces which are implementation-dependent for their semantics, it might well bite you in this way. Memory layouts of data might change, for example, and code that accidentally relied on it would break.
Seen that happen a lot of times.
Try it with different optimization options in the compile and see if that makes a difference.
Both WinARM and YAGARTO are based on gcc and should treat ld files equally. Also both are using gnu make utility - make files will be processed the same way. You can compare the two toolchains here and here.
If you are running your project with an OCD, then there is a difference between the implementation of the OpenOCD debugger. Also the commands sent to the debugger to configure it could be different.
If you are producing an hex file, then this could be different as the two toolchains are not using the same version of newlib library.
In order to be on the safe side, make sure that in both cases the correct binutils are first in the path.
If I were you I'd check the compilation/linker flags - specifically the defaults. It is very common for different toolchains to have different default ABIs or FP conventions. It might even be compiling using an instruction set extension that isn't supported by your CPU.