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.
Related
I'm developing and building applications for a various amount of platforms (linux x86, x86_64, arm, aarch64, sparc64, mips, powerpc, macos x86_64, freebsd x86_64, solaris x86_64 and of course Windows) and I was using a very old linux box (2014 Ubuntu) for all this cross-compilation.
I've recently decided that it was more than time to move to a more updated build environment as many tools were obsolete and could not be updated, so I've moved everything to a Ubuntu 22.04. All worked fine but then I hit the "glibc version hell" when I tried to run that on other boxes as glibc on that buildbox is 2.35.
So I've tried to get older glibc to compile and link against these as I'd really like to avoid linking everything static. But now, all the gcc that are build with Ubuntu have been with a "--with-sysroot=/" which, AFAII means I can't do anything. The --sysroot option is ignored by gcc which uses / for sysroot, no matter what.
I've seen a few answers saying "use old box to build" and that seems really insane to me. On my Mac or Windows, I can chose minimum (old) target platform, even if I build on W11 or Monterey. And obviously, the reason WHY I move to a new buildbox is to NOT use an old one and be stuck with obsolete tools :-).
I can probably use again ct-ng and rebuild all compilers, including native ones, but that seems really an overkill. Anybody with a better solution?
Thanks!
Seems that there is really no solution for what I'm looking for. I ended up almost re-inventing the wheel while trying to manually installing glibc. It was a faster option to use ct-ng and install cross-compilers from there, not using the stock ones provides with my distro.
The Windows binary distribution of the Linaro gnu AARCH64 ARM cross compiler (based on mingw) has a dependency on a library libwinpthread-1.dll. When I run .\aarch64-elf-gcc.exe --version I get a pop-up that says
The program can't start because libwinpthread-1.dll is missing from your computer. Try reinstalling the program to fix this problem.
For the life of me I can't seem to find anything about this library, where to find it, build it, etc. Based on the name it seems obvious that it is some pthread library for windows, but maybe not. The cross compiler is a 32-bit Windows binary for a 64 bit ARM target. The host is 64-bit Windows 10.
Any idea where I can find a 32-bit version of libwinpthread-1.dll?
The latest version of the tool chain at
https://releases.linaro.org/components/toolchain/binaries/6.1-2016.08/aarch64-elf/
seems to not have this problem of a missing dll
It can be found in
gcc-linaro-6.1.1-2016.08-i686-mingw32_aarch64-elf\libexec\gcc\aarch64-elf\6.1.1\libwinpthread-1.dll
Ed
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.
I have access to a 64 bit OS X environment, but I'd like to dramatically reduce the process for releasing native library builds for x86 / x86_64 / armv6 Linux and 32 / 64 bit Windows.
How can I cross compile JNI code from OS X (and failing that, from 64 bit Ubuntu Linux)? Which compilers must I install (I'm using macports) and from where can I install the foreign JDK environments that I must include and link against? What special compiler / linker flags are needed?
I'm using the maven-native-plugin so I can easily change the compiler, linker and JDK_HOME for every target. I have one module (i.e. pom.xml) per target platform.
The project, for those interested in details, is netlib-java/native_ref.
I've found out that various Linux cross-compilers come with macports in the form of
arm-elf-gcc
i386-elf-gcc
x86_64-elf-gcc
i386-mingw32-gcc
with 64 bit Windows cross-compile on its way.
Unfortunately, for my purposes I also need a Fortran compiler, so I'm asking for more help on that now on the macports mailing lists
EDIT: the current state of fortran cross-compilers (and mingw in general) on OS X is woeful. Best advice at the moment is to run a Linux box in VirtualBox and cross-compile all the targets from there. Two builds, not optimal, but better than all native.
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.