I'm trying to perform cross platform remote debugging from my x86 computer to a remote ARM device. (ex: Beagle Bone Black)
I'm using Ubuntu 14.04 and Eclipse CDT.
I installed the package gcc-arm-linux-gnueabihf but the gdb debugger is not in that package. (http://packages.ubuntu.com/precise/gcc-arm-linux-gnueabihf)
Therefore, I'm wondering if I should use the Linaro toolchain (which include arm-linux-gnueabihf-gdb) or if I should install the gdb-multiarch package.
What is the difference between gdb-multiarch and arm-linux-gnueabihf-gdb ?
Is it better to use gdb-multiarch ?
ssinfod
I received an answer from the linaro mailing list:
For Ubuntu hosts from 12.04 onwards, gdb-multiarch is used as gdb client for debugging. As name indicates it is a common client to any architecture and not restricted to ARM.
Generally, all gdb clients are architecture independent because architecture specific part is handled in gdbserver itself. So, other than the name arm-linux-gnueabihf-gdb, I am guessing it is same as gdb-multiarch.
I received another answer from the linaro mailing list:
The Linaro gdb release will generally be more up to date than the
Ubuntu one. For example our latest release is 7.8, and that is only
available in utopic, not trusty so if you plan to use an Ubuntu LTS
release it might be better to use the Linaro shipped gdb. Linaro gdb
also contains fixes and improvements that aren't in the upstream
stable branch. Historically Ubuntu has often picked these changes up
too but that may not always be the case.
gdb-multiarch obviously supports a range of other architectures
besides ARM, so if that is something that would be useful for you then
it might make sense to use that.
Related
I'm working on an Arduino project which was being developed on a Windows machine with the Arduino Builder. After having a release candidate, I started developing a Linux docker container that would automatically compile this project once it was pushed to my git remote. However, I noticed that the compiled binary from the Linux container is different from that of the Windows machine, in-spite of the same Arduino version and compilation flags. Is this supposed to happen? Shouldn't AVR-GCC make an equal cross-compilation result?
Thanks in advance.
Ok, so after having dug deeper into this issue and confirmed that the toolchains had the same versions (despite the different host OSs), I found out that on Linux I was not giving the linker the -flto flag for enabling the link-time optimizer, while doing it on Windows.
So all in all, there was indeed a configuration error on my part, and the code now runs smoothly when compiled on both host OSs.
I was following instructions here and here to build a toolchain which would work on Windows and compile applications for Linux and different hardware platforms. At first I tried to create cross-compiler for i686-linux to test it on a generic Debian 8 system.
Binutils and GCC compiled fine, but I got stuck at Glibc. It told me:
*** The GNU C library is currently not available for this platform.
I see that Sysprogs toolchains are using Newlib instead of Glibc but I haven't found any explanations except that Newlib is a good choice for embedded devices.
Does it mean that Newlib is actually the only choice for Windows -> Linux and that there is no way to compile software which depends on Glibc? Maybe there are "cheats", like copying pre-built Glibc from the target platform or some other workaround?
In theory, I don't even need Glibc built on Windows, I need just some "Glibc compatible stub" built for the target architecture to link (only dynamically, of course) against while compiling for the target platform and OS. Or am I totally wrong here and GCC cannot link to a different C library than GCC itself was linked to?
Or should I forget it and accept the fact that it is impossible (and, most probably, never will be possible) to achieve full Glibc and Linux kernel compatible C/C++ cross-compiling from Windows to GNU/Linux?
I will accept the answer which explains how GCC and Glibc are related and whether it is possible or not to link against Glibc different from C library used when GCC itself was built, and provide some insight about why it is / is not possible.
my guess is you're using --target when building glibc when you really need to use --host (which is different from how newlib is configured -- best to not ask why).
that said, the glibc build system requires a case-sensitive file system as it creates files like foo.oS and foo.os which are very different things. on a system like Windows, that means the build will be corrupted and fail since foo.oS and foo.os refer to the same file. there are patches out there to hack around this, but really you'd be better off booting a VM and doing the toolchain build inside of that.
NB: i'm not saying you need the VM to do all your development. you just need the VM to build the cross-compiler which you'd then run under Windows. this would be a canadian cross build.
rather than do all this yourself by hand, please check out crosstool-ng. it handles/patches/fixes a lot of common errors people make when trying to create cross-compilers.
Not exactly programming/code related, but related to Linaro compiler utilities toolchain.
I am trying to find a Linaro toolchain for Windows platform for armv7-a architecture, but which is compiled/configured with a soft floating point abi i.e. --with-float=soft
I have searched here but there is none which i am looking for.
If there isn't any I would try to build one. Towards that, would appreciate pointers about how to build a linaro toolchain.
What are steps involved in building the linaro toolchain either on Ubuntu Linux or on a Windows under cygwin?
If you go further back (to 12.04) you can find the older, non-hf versions. The instructions to build them are in the README.txt. The README.txt, source and crosstool package are in the same place. You use an Ubuntu machine to build the Windows-hosted tools.
If I want to compile a program that is written in Ada, I have to use GNAT, of course.
As my Computer has Windows as its sole operating system, I cannot use GNAT, normally. Right? Thus I got Cygwin which enables me to use GNAT on Windows.
But the result is an executable that runs under Windows - not Linux. So how can I compile the Ada code for Linux although I only have Windows? (Please don't think about the reasons ...)
Is this possible with Cygwin? Do I have to install a virtual machine with Linux? Or is there another (easier) solution to this issue?
I have to use GNAT, of course.
Not true; there are other Ada compilers. (GNAT is the only one I know of that's free.)
Running GNAT under Cygwin gives you Cygwin executables, which are Windows executables that depend on cygwin1.dll. They will not work on Linux. See the "What ... isn't it?" section on the Cygwin home page.
There is a GNAT for Windows. The GNAT Pro version has a list of supported platforms here; it includes Linux and Windows, but it doesn't show a Windows-to-Linux cross compiler.
Since GNAT is free software (GNAT Pro isn't is a little more complicated; I won't get into that) there could well be a Windows-to-Linux GNAT cross-compiler -- or, if you're really ambitious, you could build one yourself (or hire someone to do it for you).
But installing GNAT on a Linux system is the easiest approach. It doesn't have to be a virtual machine. If you have the hardware, you can install some Linux system by itself, or you can set up a dual-boot system on your Windows box. Ubuntu has a Windows installer, Wubi, that installs an Ubuntu image as a Windows file; it doesn't let you run Windows and Ubuntu concurrently, but it lets you dual-boot without having to repartition.
There are other options; these are just the ones I'm familiar with.
Is this possible with Cygwin?
It's probably possible.
Do I have to install a virtual machine with Linux? Or is there another (easier) solution to this issue?
Installing a Linux on a virtual machine is likely to be the simplest solution to your problem.
Since GNAT is free software (GNAT Pro isn't; I won't get into that) there could well be a Windows-to-Linux GNAT cross-compiler -- or, if you're really ambitious, you could build one yourself (or hire someone to do it for you).
Actually GNAT Pro is Free Software, free as in freedom, not as in beer.
And I think that it would be simplest to install Linux in virtual machine and compile with it.
AdaCore has a gnat compiler for the Windows operating system freely available at: http://libre.adacore.com/libre/download/ and choose "Free Software..." and click "Build Your Download Package" and go from there. As Keith Thompson suggests, you can setup a dual-boot solution if you actually need a Linux compatible executable. Remember any program compiled on Windows results in a Windows-only executable unless you have a compiler that allows for cross-compilation.
It became possible for them who use Windows 10 64 bit with new "Linux Subsystem" feature. You may install gnat on it and use it to compile ELF binaries, as well as windows binaries.
My distribution (Arch Linux) recently increased the minimum supported Linux kernel version for its toolchain. I am compiling a web application that I link statically and then upload to a web server, and the kernel version on the web server is too old for static libraries compiled with the new toolchain. (I get a segmentation fault when I try to run static binaries on the server.) Is there a way to compile applications using the GNU toolchain (GCC, binutils, glibc) such that features requiring newer kernel versions are left out?
Glibc compatibility is really only guaranteed in one direction. (Older binaries work on newer systems; vice versa, not necessarily so.)
To guarantee that your binaries work on older systems, compile linking with an older glibc. The easiest way to do this is to find an older distribution, but I would recommend setting up a "crosstool" or similar cross-compiling toolchain targeting a different libc than what your build system uses (and this allows for repeatable builds across hosts regardless of what the system is).
Thanks. I also found the --enable-kernel option to glibc, which enables working with earlier kernels.