I was trying to install Sourcery G++ cross-compiler for ARM on Ubuntu 10.04 LTS from the following link ->http://www.codesourcery.com/sgpp/lite/arm/portal/release644
I did not use the graphical interface since I got java.awt error. While using the console mode of installation, I provided all the details asked by the program.(changed the default location of installation)
Some time into the installation, I got this error:
Unable to create file links
An error occurred while running an internal program.
Please remove the toolchain from "/home//cross_compiler".
EXITCODE=-1
I'm not sure what the reason is. I redid this process as a root user and I still got the same error.I am trying to install this on a 64 bit machine.
I suppose it is important to check your system requirements.
There is the possibility you are running a 64bit build of Ubuntu.
Sourcery G++ requires 32bit host libraries. Ensure those are installed.
In my mind, it may be easier to run a 32bit installation in a VM.
If that is not possible, there are installation logs in the 'uninstall' directory of your installation attempt directory. That may help you troubleshoot the issue.
You must have the 32-bit compatibility libraries installed to install Sourcery CodeBench.
From the FAQ: "What do I need to do to install and run Sourcery CodeBench on an x86 64-bit Linux host system?"
https://sourcery.mentor.com/sgpp/lite/arm/portal/kbentry62
Full FAQ here:
https://sourcery.mentor.com/sgpp/lite/arm/portal/target_arch?#action=faq&target_arch=arm
The ARM Lite edition tools have their own mailing list where you can ask such questions.
Go to sourcerytools.com and use the "arm-gnu" mailing list for ARM Lite edition questions.
Cheers!
Related
I'm trying to cross-build LÖVE (https://love2d.org) for an ARM Linux device (Rockchip RK3066) from Ubuntu 16.04.
As the documentation says, I installed all dependencies on Ubuntu and was able to build it (for Ubuntu, as a test). Now I'm going for the cross-build.
Before building, I have to run ./configure. So far I've been able to get the toolchain's gcc compiler to be accepted, but when it looks for the dependencies, I get this error:
checking for luajit5.1... no
checking for luajit51... no
checking for luajit... no
configure: error: Package requirements (luajit) were not met:
No package 'luajit' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables lua_CFLAGS
and lua_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
Could this be fixed by cross-building luajit for the device and add it to the toolchain binaries, or could I just try to make the ./configure script look for the luajit I installed in Ubuntu?
If it's the latter, would someone kindly point me on the right direction? I've opened like 20 pages already with a similar error message and none of them had a valid answer.
Thanks a lot in advance.
When I try to add it to sources as per debian install instructions I get this error. I'm guessing this means that there are no arm packages for it.
Failed to fetch https://dist.crystal-lang.org/apt/dists/crystal/InRelease Unable to find expected entry 'main/binary-armhf/Packages' in Release file (Wrong sources.list entry or malformed file)
I'm guessing I probably need to install it from source. How would I go about doing that with an arm cpu? When I check it out and run make I get the error:
You need to have a crystal executable in your path! Makefile:113:
recipe for target '.build/crystal' failed make: *** [.build/crystal]
Error 1
Any suggestions would be greatly appreciated.
EDIT: There's now a semi-official repository for crystal on raspbian, check it out here: http://public.portalier.com/raspbian
Crystal doesn't build Debian packages for ARM, and you're correct in that you'll need to build from source.
However, the Crystal compiler is written in Crystal. This presents the obvious problem of how to get a compiler to build the compiler. The answer is cross-compilation: building an arm binary on a x86 desktop computer and copying it across.
Here's a quick step-by-step based on my memory of last time I cross-compiled:
Install Crystal on a x86 desktop PC, and check it works.
Install all required libraries on the desktop and Raspberry Pi. You'll need the same LLVM version on the Raspberry Pi and desktop. This is probably the hardest and longest step. You can install llvm 3.9 from debian testing for ARM, see this stackoverflow post for how to install only LLVM from debian testing.
Check out the sources from git on both computers, and run make deps.
Cross-compile the compiler by running this command in the root of the git repository:
./bin/crystal build src/compiler/crystal.cr --cross-compile --target arm-unknown-linux-gnueabihf --release -s -D without_openssl -D without_zlib
This command will create a crystal.o file in your current directory, and also output a linker command (cc crystal.o -o crystal ...).
Copy crystal.o to the raspberry pi, and run the linker command. Be sure to edit the absolute path to llvm_ext.o so that it points to the Crystal checkout on your Raspberry Pi, not the checkout on your desktop. Also make sure that all references to llvm-config in the command are for the correct LLVM version. For example, changing /usr/local/bin/llvm-config to llvm-config-3.9 on Raspbian.
Run the crystal executable in your current directory (./crystal -v) and make sure it works.
Ensure to set CRYSTAL_PATH environment variable is set to lib:/path/to/crystal/source/checkout/src so that the compiler can find the standard library when compiling applications.
I am trying to compile a small utility called tcpslice. It's the typical GNU C application. When I run ./configure, here is the output:
checking build system type... Invalid configuration `x86_64-pc-linux-gnuoldld': machine `x86_64-pc' not recognized
configure: error: /bin/sh ./config.sub x86_64-pc-linux-gnuoldld failed
It appears to not support compilation as a 64-bit Linux application. So I have a few questions:
Is it possible to set some flags to compile the application as 32-bit AND be able to run it on my 64-bit operating system?
Is it possible to update the configure script to support 64-bit Linux? If so, will I be making some serious code changes in the .c files as well?
I noticed a 64-bit RHEL6 machine on my network has this utility installed and running with an identical version number (1.2a3). Could I somehow download the source that was used to build it? I can get access the to RHN if necessary.
Is it possible to set some flags to compile the application as 32-bit AND be able to run it on my 64-bit operating system?
Yes. -m32 is the option.
Is it possible to update the configure script to support 64-bit Linux? If so, will I be making some serious code changes in the .c files as well?
You will have to make some code changes to make a purely 32 bit application work on 64 bit. Here's a link that talks about porting code from 32 bit to 64 bit.
I am sorry, I do not know the answer for your 3rd question.
Hope the little information provided by me helps in some way.
You've misinterpreted what the configure script is telling you. The solution has nothing to do with CPU bitness.
The error comes down to a too-old version of config.guess, which the package creator generated with libtoolize. To fix it, you will need to have libtool installed, then say:
$ libtoolize --force
You'll find that configure now runs, because libtoolize overwrote the tarball version of config.guess with one appropriate to your system.
You may run into another problem, a "missing" bpf.h file. Just edit tcpslice.c and change this line:
#include <net/bpf.h>
to:
#include <pcap-bpf.h>
With those two changes, I got tcpslice to build on my 64-bit CentOS 5 box.
install following packages :
$apt-get install ia32-libs.
for rhel its different :
look at the answer to this question :
CentOS 64 bit bad ELF interpreter
I've compiled a C program under Ubuntu 12.04, built a Debian package out of it, and want to install it on a server running Debian Lenny.
Last time I did that (about two months ago) it worked: I could install the package and run the binary. But now I get the following error message:
(binary's name): /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by (binary's name))
Other than upgrading my machine to Ubuntu 12.4, the only significant change we've brought to the code is a call to strdup(), for which I had to enable the _POSIX_C_SOURCE=200809L feature test macro.
Upgrading the server to the latest Debian version is not my preferred option as it is not under my direct control.
How do I fix this problem?
I think the critical bit of info here is 'upgrading my machine'. So when this worked before, you were building and packaging on something earlier than 12.04? If so, then the issue is that 12.04 now ships with a newer version of libc (apparently 2.14), and your binary now records a dependency on that version of libc. When you try to run on Lenny, which likely uses an older version of libc, the linker detects that the Lenny version does not support the 2.14 API, and fails.
I think the best way forward is probably to do your development and testing on 12.04, and then when you want to create packages for a specific Debian release, use pbuilder or similar to create debs. This will ensure that the libraries used for the packaging build match the target platform.
I just got Macports installed on my mac, of which os version is Snow Leopard (10.6). I used Macports to install several packages through 'sudo port install' command, and all these packages are reported active after the installation. I just wonder that whether these packages are really working? For example, macports tells me that 'gcc44 #4.4.2_0 (active)', however in python it says '[GCC 4.0.1 (Apple Inc. build 5493)] on darwin'.
So I just want to know that if there is some problem with my method of installing or my macports needs some configuration after installation?
Any help is appreciated! I am really new in Mac OS.
I believe Python is declaring the version of gcc used to build it which should be the gcc installed on your Mac i.e. the version that came with the Mac OS Development tools. This should be located in /usr/bin/gcc.
You should find the gcc version matches when you execute
/usr/bin/gcc -v
I do not think anything is wrong with your setup or configuration. It just shows Python was compiled using the gcc provided by Apple
Macports installs software not to conflict with the versions provided by Apple. If they replaced the C compiler and libraries, really bad things might happen when Apple provided operating system updates.
gcc is the command for Apple's version of gcc, at /usr/bin and version 4.0.1 for Leopard.
gcc-mp-4.4 is the command for gcc version 4.4 as provided by MacPorts, located at /opt/local/bin.
Similarly there will be versions of python in /opt/local/bin.
Like houmam, I prefer to explicitly invoke versions by name. If you want to connect particular versions to python, I think that the MacPorts package python_select (this has now been replace by port select python) implements this by using symbolic links. I've never used it.
It probably is just that compiler that was picked by the build was that installed by XCode. You can try typing which gcc to see which one is in your path. The macports one would by default be in /opt/local somewhere.