modifying buildroot for non- linux freertos
Hi,
I have been using buildroot for embedded linux builds for a while now and think its great. Now I want to use the shell scripts and the general buildroot environment to build freertos using newlib rather than uclibc.
I have prototyped this but have run into some not unexpected problems and thought you guys might be able to help. If you consider this email just spam flame me now and I will go quietly on without further disturbing you.
I want to do this because I want control over my build environment, because I need OpenOCD, gdb etc etc and because if the tools are ok for my embedded linux environment then I can save effort by using close to the same tools for simpler freertos solutions. The buildroot style seems just what I need to solve my problem and would allow me to have all the control over my build environment that I need in one place.
Stage 1 is to get the tools built and I only need shared libraries so that should be simpler. I keep configuration simple and just have a build freertos configuration file (bf1_config) with all the config stuff I find I need so I avoid .config and menuconfig for now. I use the scripts in support and build packages from package (so far I found I need zlib, perl, mpfr, mpc, m4, libtool, gmp, expat, binutils, automake, autoconf). The tools I am building are patched from files in toolchain (so far I have newlib, gdb, gcc).
The problem originates because newlib (http://sourceware.org/newlib/)
has a different build style to uClibc but using uclibc.mk as a starting point for newlib.mk and making major mods I can get most things working. I have built all the output/host/usr/bin tools but $(GCC_BUILD_DIR3)/.installed target has not been run so there is no $(HOST_DIR)/usr/bin/$(GNU_TARGET_NAME)-cc but my newlib build is trying to use it. So what I think I need to do is delay the build of newlib and I am not sure how to do that yet. So I am puzzling over $(GCC_BUILD_DIR1)/.configured:, $(GCC_BUILD_DIR2)/.configured: and $(GCC_BUILD_DIR3)/.configured: targets and wondering to myself what bit in buildroot sequences these and how can I fit my new newlib targets into the right place in the build sequence. If you have read up to this point you may have a view or some tips. Perhaps there is a good guide that I have missed that could help? I did a search of the archive but did not find anything that was of immediate assistance. Perhaps there is a better place to ask this question? Perhaps is such an interesting problem that you would like to see me create a new git project for it?
Thanks for your time.
Peter.
Hi Peter,
On 15/04/13 23:53, Peter Saunderson wrote:
[snip]
Quoted 9 lines
The problem originates because newlib (http://sourceware.org/newlib/) has a different build style to uClibc but using uclibc.mk as a starting point for newlib.mk and making major mods I can get most things working. I have built all the output/host/usr/bin tools but $(GCC_BUILD_DIR3)/.installed target has not been run so there is no $(HOST_DIR)/usr/bin/$(GNU_TARGET_NAME)-cc but my newlib build is trying to use it. So what I think I need to do is delay the build of newlib and I am not sure how to do that yet. So I am puzzling over $(GCC_BUILD_DIR1)/.configured:, $(GCC_BUILD_DIR2)/.configured: and
Quoted 8 lines
$(GCC_BUILD_DIR3)/.configured: targets and wondering to myself what bit in buildroot sequences these and how can I fit my new newlib targets into the right place in the build sequence. If you have read up to this point you may have a view or some tips. Perhaps there is a good guide that I have missed that could help? I did a search of the archive but did not find anything that was of immediate assistance. Perhaps there is a better place to ask this question? Perhaps is such an interesting problem that you would like to see me create a new git project for it?
I'm afraid that the expertise on the internal buildroot toolchain build
process is not here anymore. Some buildroot developers understand how the .mk file works, but not really why things were done in that particular way...
But anyway, I don't think you really need buildroot for this. Buildroot
is meant for building packages for the target, and just builds some host packages that are needed for building some of these packages. I think crosstool-NG is a much better fit for your purpose. It's build system is pretty complex, but I think it's still easier to understand than the buildroot system. Also, crosstool-NG might be interested in adding support for newlib (as an alternative to uClibc) in its core infrastructure.
BTW, you could also consider looking at musl instead of newlib.
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
Peter, Arnout,
Quoted 11 lines · Arnout Vandecappelle
I'm afraid that the expertise on the internal buildroot toolchain build
process is not here anymore. Some buildroot developers understand how the .mk file works, but not really why things were done in that particular way...But anyway, I don't think you really need buildroot for this. Buildroot
is meant for building packages for the target, and just builds some host packages that are needed for building some of these packages. I think crosstool-NG is a much better fit for your purpose. It's build system is pretty complex, but I think it's still easier to understand than the buildroot system. Also, crosstool-NG might be interested in adding support for newlib (as an alternative to uClibc) in its core infrastructure.
Crosstool-NG already has support for newlib.
Peter, I agree with Arnout here. The main point of Buildroot is to build a root filesystem with Linux applications and libraries, and this is not something you could re-use on FreeRTOS.
You should therefore definitely have a look at Crosstool-NG to produce a newlib toolchain that works for FreeRTOS.
Best regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com