I have been following the instructions here to compile an avr cross compiler toolchain on my x86 PC. I had to do some searching on the step for compiling gcc because it was complaining about some missing dependencies, turns out there was a a script I could just run which downloaded the pre-requisites.
Now however, I am stuck on the step where I'm supposed to compile avr-libc. I get this error:
blah#blah-computer:~/avr/avr-libc-1.8.0$ ./configure --prefix=$PREFIX --build='./config.guess' --host=avr
checking build system type... Invalid configuration `./config.guess': machine `./config.guess' not recognized
configure: error: /bin/bash ./config.sub ./config.guess failed
From my googling of this problem, it seems there might be something wrong with my installation of autotools, and I actually remember seeing some warning about autotools when I was compiling gcc but as far as I could tell that step was actually successful.
Could anybody give me a good quick explanation of what autotools is and maybe help me fix my problem?
I don't see why you would need to specify --build at all. Just set the environment variable: CC=avr-gcc (the AVR cross compiler), and use --prefix=... and --host=avr as before. AVR-libc will set the CFLAGS to the 'best' values as it builds each ISA version in the multi-lib.
However, if you want to specify --build, use the backtick characters rather than the single-quote characters to execute the script: --build=`./config.guess`
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.
I ran across an interesting issue. My system is Arch Linux (latest) on an ASUS laptop. Now, the really weird issue:
finger is not automatically installed with Arch. I attempted to use pacman to install it, and it's not in the repositories. It IS in the AUR.
I downloaded the AUR file, un-tarred the tar with tar -xvf bsd-finger0.17.tar.gz. This created the directory folder with the same name. I ran ./configure which gave the expected output:
` /usr/man
Looking for a C compiler... gcc
Checking if gcc accepts gcc warnings... yes
Checking if gcc accepts -O2... yes
Checking for socklen_t... yes
Checking for snprintf declaration... ok
Checking for snprintf implementation... ok
Generating MCONFIG...`
Then I tried to make, and got this weird tidbit: http://pastebin.com/0qACttCu
So, it looks like it's having weird compiling issues. Any ideas on what's up here?
I have no idea what AUR is, but it seems you are not using it the way it is supposed to be used.
https://wiki.archlinux.org/index.php/Arch_User_Repository#Build_and_install_the_package
That wiki says that you should build an AUR package with "makepkg"
But anyway looking at
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=netkit-bsd-finger
It seems you just need to add time.h as include to two files and it should compile.
I tried this command to configure thrift,
./configure CXX=arm-linux-gnueabi-g++ CC=arm-linux-gnueabi-gcc --prefix=/arms/thrift --host=arm-linux-gnueabi --with-cpp --with-boost=/path-to-boost-for-arm
and met the following error msg
checking for boostlib >= 1.40.0... yes checking for libevent >= 1.0...
configure: error: in `/arms/thrift-0.9.0': configure: error: cannot
run test program while cross compiling
Is there any solution?
You get the error because a dependency it's trying to find is missing. So first cross compile all the dependency it's searching for.
./configure --help
Here you find how to include dependencies.
--with-(dependency)=path-to-compiled-bin
Thrift 0.9.0 is BROKEN for cross-compile. Part of the problems you're seeing are because they have static paths for at least a few (if not all) of the stuff that doesn't offer pkg-config stuff answers for things. It's looking outside of your sysroot for all sorts of things right now.
There's an issue logged in their Jira, but the position they take is "have you set your --includedir parameter?" (Uh, --includedir is specifying where things are within my sysroot, and you're supposed to honor things like turning off PHP builds (it doesn't right now...sigh...) and a --with-libtool-sysroot that prefixes everything so you can cross-compile.) So, I don't think help will be forthcoming anytime in the immediate future.
I've compiled clang to use it as a cross compiler for ARM (by configuring it with ./configure --target=armv7l-unknown-linux-gnueabihf ), but when I try to compile any C code, it tries to use /usr/bin/as. I already have binutils compiled for ARM, and they are in a separate directory. How do I direct clang (or llvm) to use the assembler that I specify?
try passing the --host option to configure which will cause all the cc ar etc utilities to prefix with armv7l-unknown-linux-gnueabihf-
eg:
./configure --host=armv7l-unknown-linux-gnueabihf --build=i686-unknown-linux-gnu
Since you are using configure with hopefully autotools take a look at:
automake Cross compiling
I've always had trouble configuring from the source directory using ./configure and gave up in the end. These days I always configure from a separate directory i.e. ..//configure although I'm told it's recommended to use an absolute path for configure.
Your ARM binutils should be installed in the same prefix you're using for clang and make sure that they're in the path when you configure & build clang - i.e. PATH=/some/prefix/bin:$PATH; /configure --target=armv7l-unknown-linux-gnueabihf. If you're keeping them in separate directories for packaging purposes then make install DESTDIR= should help.
I don't generally build clang but the buildscripts I use for devkitARM might be helpful - http://sourceforge.net/p/devkitpro/buildscripts/ci/c372699fc7b4de90eb044314ce5bed04db640291/tree/
I'm trying to compile a simple hello world application to be run on uCLinux (2.4) which is running on a board with a Freescale Coldfire (MCF5280C) processor...and I'm not quite sure what to do here.
I know I need to compile with the correct version/tools from Freescale to target this hardware, so I downloaded and installed the Coldfire tool chain and verified that one I have is for my target:
mike#linux-4puc:/usr/local/m68k-elf/bin> ./gcc -v
Reading specs from /usr/local/lib/gcc-lib/m68k-elf/2.95.3/specs
gcc version 2.95.3 20010315 (release)(ColdFire patches - 20010318 from http://fiddes.net/coldfire/)(uClinux XIP and shared lib patches from http://www.snapgear.com/)
I tried a simple gcc "file" type command:
mike#linux-4puc:/home/mike> /usr/local/m68k-elf/bin/gcc test.c
/usr/local/m68k-elf/bin/ld.real: cannot open crt0.o: No such file or directory
collect2: ld returned 1 exit status
Which does not work at all.. so it's clearly more complex that than. The output almost looks like it wants me to build the tool chain before I use it?? Anyone ever done this before? Not sure what I need to do or if I just need some flags.
You might also try seeing if you have a command called m68k-elf-gcc or something along those lines. This is a common naming for cross-compilers.
As for your problem, it sounds like there is something wrong with your compiler setup. crt0.o is the object file that contains C-runtime setup code. The linker (what is actually giving the error) should know where this file is if setup properly.
When you installed you should have run make install as the last step without having modified anything since the make step. The configuration step will setup certain variables and such based on the path where it's supposed to be installed.
Where did you get a FreeScale toolchain? I took a look at their site and it seemed only third parties supplied C++ cross-compilers. In the toolchain I get from NetBurner (for use with their hardware) the crt0.o file exists under the gcc-m68k\m68k-elf\lib directory.