Why not Makefile based? about bleeding-edge-toolchain HOT 6 CLOSED

Hello @ponyatov !

I've been on a long-deserved holidays and returned just a few days ago, that's why I'm replying with a delay.

Your Makefile is small and simple, but it doesn't have that many features as available in the script here. Please note that the script which builds bleeding-edge-toolchain also has features like:

• downloads the archives from the web, only if not already downloaded,
• extracts the archives,
• patches the extracted sources (only in some versions, when this is required),
• configures the packages,
• compresses the whole toolchain into a nice archive,
• allows you to also build a toolchain for Windows,
• allows you to select whether you want the docs and/or the "nano" variant of the libraries,
• ...

This way the script is the ONLY file you need. You also don't need to do any additional steps before using it (except installing appropriate tools in your system). With your Makefile there's a lot you have to do before running it and there's no way to customize the result in any way.

These features are of course also possible with Makefile, but I guess they wouldn't be so simple and small, right? (; In this case you would use the Makefile as a shell script anyway, so why not just use shell directly?

Please let me know whether you have any more questions regarding the bleeding-edge-toolchain!

from bleeding-edge-toolchain.

Does the generated toolchain support LTO properly? Can be tricky for Windows especially.

from bleeding-edge-toolchain.

@Trass3r - there is nothing specific in bleeding-edge-toolchain which would make LTO work better or worse. It provides LTO support in the state exactly the same as the components used (basically gcc and binutils). If something is broken in the components, then it will be broken in bleeding-edge-toolchain as well, however if something is working correctly in gcc & binutis, then bleeding-edge-toolchain will support that with no issues.

bleeding-edge-toolchain is just a script which builds vanilla components to be used with ARM microcontrollers.

Last time I tried LTO with one of my projects it was working fine, but the project itself required some tweaks here and there (mostly adding __attribute__ ((used)) for some of special functions). It is not guaranteed that a project which works without LTO will work after enabling LTO - in my opinion such behaviour is expected and this is normal, not a bug in the toolchain, especially when dealing with stuff like interrupts, strange linking strategies and so on (basically regular stuff used when dealing with microcontrollers). Since then I did not try it, as my main issue with LTO is that it produces an executable which cannot be debugged (at least this was the case when I tried) and the gains are not so spectacular for me to bother. This was in 2017, so with gcc 7.

from bleeding-edge-toolchain.

I'm asking because crosstool-ng has problems with creating the proper LTO plugin dll for windows (tries to create an .so instead) and https://gnu-mcu-eclipse.github.io/blog/2019/04/26/arm-none-eabi-gcc-v8-2-1-1-5-released/ is also still struggling with it. And there are general problems like a static toolchain build silently disabling the LTO plugin etc.

from bleeding-edge-toolchain.

In that case I don't know, you have to try it yourself and let me know - I'm not using Windows.

from bleeding-edge-toolchain.

my main issue with LTO is that it produces an executable which cannot be debugged (at least this was the case when I tried) and the gains are not so spectacular for me to bother. This was in 2017, so with gcc 7.

Should be ok now:
https://hubicka.blogspot.com/2018/06/gcc-8-link-time-and-interprocedural.html

from bleeding-edge-toolchain.