I am using buildroot's toolchain to cross compile applications for ARM. However some application requires libraries that are not compiled for that tool chain. I have those libraries on my host tool chain like -ljack, lfftw etc.
I need to know that if I get tarball of the required packages then how can I configure them so that the libraries are compiled by arm-gcc and the headers/libraries copied to /usr and /include of the buildroot ?
In this way I should be able to access these libraries via buildroot's toolchain.
Thanks,
Well, you need to integrate them into Buildroot.
Take fftw for example, in that particular case, fftw is already available in Buildroot, and you just have to enable it in your build. Go to Target packages->Libraries->Other and enable fftw.
If you don't know where to find a package, run make menuconfig and type Ctrl-/ to get a search box. There you could type e.g. fftw and learn where in the menu system it is located and what dependencies it has.
If fftw (or some other library you need) hadn't been / isn't available in Buildroot, you need to add it yourself. See e.g. adding packages to Buildroot.
Related
I'm working on a cross-platform project which requires dependencies which are not available on my machine. I basically use a cross-platform tool-chain in docker to build everything. Using buildroot I build a whole Linux system for an ARM platform.
So, I was wondering if there is an option to let Clion know or pick another path for system include header files? Then at least clion can help with code completion etc.
I downloaded crosstool-ng-1.24.0, not yet installed. I want build cross toolchain for ARM target, but I need specific components versions run on target ARM board, for which the toolchain generates code, Linux kernel 2.6.26.5, gnu gcc 4.1.2, glibc-2.5
Since crosstool-ng toolchain have no these components, how I can add and install it? I checked toolchain sources and documents but didn't find any instruction on that. The 'packages' folder contain separate components, but in form of patches. I would prefer download the required components and put these locally, in folder. How to make these correctly?
I am building Go code that uses CGo heavily and this code must be compiled into a shared or static library (static is highly preferred). (code for reference)
It all works just fine on Linux and Mac, but on Windows it fails on linker stage either saying that all 4 modes (c-shared, shared, c-archive, archive) are not available or if invoke go tool link -shared manually complains about missing windows specific instructions.
My understanding is that all I need to build usable lib.a is to compile everything I will use into object files (*.o) and then put it through ar to produce usable static library.
Now the question is whether I can completely skip Go's linker and based on prepared .o files create .a manually?
How would I go about doing that if that is even possible?
Looks like gcc on windows is unable to automatically discover necessary shared libraries. The problem was caused by GCC and not by Go.
Although for compiling Go I had to use self-compiled master tip as current release (1.6.2) does not support shared/static libraries on windows/amd64.
Manually feeding gcc with each shared library (ntdll, winmm etc) in default location (C:\Windows\SysWOW64) has fixed the problem.
Could anyone offer some suggestions (or resources) on how I could package a GO program that uses git2go, libssl and libssh2 such that it doesn't require the end user to install these libraries separately?
I am only targeting Linux distros (if it matters)
One way would be to build those dependencies statically as well and use PKG_CONFIG_PATH point to your own copies so everything gets linked statically. That should make CMake choose the static versions.
But if the goal is to avoid depending on the user-installed libraries rather than making everything a single executable, I would recommend shipping the libraries and working with the load path to make sure they get loaded. With gcc you'd pass -Wl,-R to set the search path in the binary itself, so you can set where to search for the shared libraries you're shipping with your app. With go it looks like you can pass -r to the linker (via -ldflags or manually) to do the same thing.
libgit2 is rather extensible, so there is a third option which is to implement the TLS stream and SSH transport in Go and plug those into a version of libgit2 without support for these. This is however a significant amount of work.
Of course we all know building GCC version >= 4.1.x requires the supplementary packages MPFR, GMP and MPC to be present.
There's a few ways to handle these GCC dependencies:
1) Download and build each supporting package separately and then tell make where the binaries are located during GCC build time.
2) Download each supporting package, untar and move the source into your GCC build directory and make will automatically build each of the packages when needed.
(Executing the gcc-src/contrib/download_prerequisites script does the same as option 2)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Is there an advantage to either method? Does pre-compiling the binaries provide something I'm missing by taking the "easy route" and just dumping the package's source into my GCC build directory and letting make figure it out?
I've seen it done more frequently in various build scripts by pre-compiling each package to a binary, and then telling make where they are located during gcc compilation. Is this the "preferred" way to do it? Why?
To add context, I'm mainly building cross-compilers targeting various ARM platforms.
For most use cases I believe that option 2 is just as good as option 1. However, I can see a few situations in which one would want to do it manually.
A package maintainer wants to build separately as they want separate packages for mpfr et al.
Someone who wants to pass different configure arguments/CFLAGS to each of the packages.
A GCC developer who wants to keep their source and build trees small as they don't make any changes to MPFR/GMP/etc.
I haven't done too much work with the (rather ugly) GCC build system, but I haven't seen any obvious differences in how the binaries are built.
I'm not the biggest authority on this though, so YMMV; I may be wrong.