I recently downloaded and installed ARM cross-compiler CodeSourcery on my host machine running Ubuntu 13.04.
I want to cross-compile a kernel driver by running make. Makefile contains parameter CROSS_COMPILE := arm-none-linux-gnueabi-. How can I add cross-compiler to the PATH?
Is it the same by editing Makefile with the path that cross-compiler is located?
e.g. CROSS_COMPILE := /home/demetres/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin/arm-none-linux-gnueabi-
You need to export following things:
export ARCH=arm
export PATH=/home/demetres/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin/:$PATH
export CROSS_COMPILE=arm-none-linux-gnueabi-
After doing this you can call make menuconfig, make etc.
You can put all these export commands into a script file and invoke via source command before compiling/configuring your kernel.
You should not edit Makefile for this, most of the times, temporary changing of PATH is enough.
orgPATH=$PATH
export PATH=/home/demetres/CodeSourcery:$PATH
make
export PATH=$orgPATH
Related
I've searched on the nixos package manager, if there is package named locate.
Yes and several. But that's not the bash command that I am searching for.
I want to add this bash command
locate name.extention
which gave me the path of this file
The package mlocate provides a locate executable. The package plocate provides an executable named plocate which might be better. Both of these packages will require some extra setup steps to allow them to build their file location database, and I don't happen to have a link to those instructions at the moment.
nix-shell -p mlocate
I have an environment file named .env337_dev. I need to run this file to set the environment before running another command. How to run this file?
Inside the file, it contains several variables like this
export AB_HOME=/et/dev/abinitio/sit1/abinitio-V2 #/gcc3p32 # for 32-bit
export PATH=${AB_HOME}/bin:${PATH}
Apart from . ./.env337_devcommand which will run and set the environment, is there any other way to run this file ?
Are you looking for the user-specific .bashrc (bash is the default shell on RHEL 6) or a system-wide /etc/profile.d/<something>.sh? For the first, you would edit $HOME/.bashrc and append a line like . .env337_dev (it's still run before any "regular" command, because .bashrc is the Bash standard personal initialization file). Second option suggests that you use an absolute path.
If this doesn't answer your question, a more specific question and/or more details would be very helpful.
You tagged this ab-initio, so you should only be setting a very few environment variables, including:
export AB_HOME=<path-to-co>operating-system>
export PATH=$AB_HOME/bin:$PATH
If you are working with Ab Initio web applications:
export AB_APPLICATION_HUB=<path-to-application-hub>
export JAVA_HOME=<path-to-jdk>
export PATH=$JAVA_HOME/bin:$PATH
and specific settings for different applications, e.g.
export AB_MHUB_HOME=<path-to-metadata-hub-installation>
Typically you put those into the file .profile in your home directory, which shells evaluate for interactive sessions.
I am trying to run a tool that uses Clang and LLVM. The tool name is cppgrep that is available with the docker. Please find it from the github repository - https://github.com/peter-can-talk/cppnow-2017. I have tried using Ubuntu 16.04 and 17.10, I got the same error as below:
root#522051d201d2:/home# ./cppgrep -help
./cppgrep: /usr/lib/x86_64-linux-gnu/libLLVM-4.0.so.1: version `LLVM_4.0' not found (required by ./cppgrep)
./cppgrep: /usr/lib/x86_64-linux-gnu/libclang-4.0.so.1: version `LLVM_4.0' not found (required by ./cppgrep)
root#522051d201d2:/home#
After some online search, I found that I had to setup the environment variable LD_LIBRARY_PATH. So as a first step I found the library files location in the docker, please find the output below:
root#522051d201d2:/home# find / -iname *libclang*.so*
/usr/lib/x86_64-linux-gnu/libclang-4.0.so
/usr/lib/x86_64-linux-gnu/libclang-4.0.so.1
/usr/lib/llvm-4.0/lib/libclang.so.1
/usr/lib/llvm-4.0/lib/libclang-4.0.so
/usr/lib/llvm-4.0/lib/libclang-4.0.0.so
/usr/lib/llvm-4.0/lib/libclang.so
/usr/lib/llvm-4.0/lib/libclang-4.0.so.1
/usr/lib/llvm-4.0/lib/clang/4.0.0/lib/linux/libclang_rt.dyndd-x86_64.so
/usr/lib/llvm-4.0/lib/clang/4.0.0/lib/linux/libclang_rt.asan-i686.so
/usr/lib/llvm-4.0/lib/clang/4.0.0/lib/linux/libclang_rt.asan-x86_64.so
/usr/lib/llvm-4.0/lib/clang/4.0.0/lib/linux/libclang_rt.asan-i386.so
After this step, I setup the LD_LIBRARY_PATH as follows:
root#522051d201d2:/home# echo $LD_LIBRARY_PATH
/usr/lib:/usr/lib/llvm-4.0/lib/:/usr/lib/x86_64-linux-gnu/
And lastly, I have exported it using the command export LD_LIBRARY_PATH. Now, if I try to run the cppgrep tool, I am still getting the same error. The command to test the tool after building the docker is as follows:
(1) cd into the cppgrep directory, like code/cppgrep,
(2) enter the docker container and mount the folder under /home:
$ docker run -it -v $PWD:/home clang
(3) run cppgrep using ./cppgrep 'x' test.cpp command.
It is suppossed to return functions and variables that has name x.
To replicate the error, after downloading and unzipping the file from github repository, build the docker container using $ docker build -t clang . command. Then follow 1,2,3 steps in the above paragraph.
After couple of days struggle, solved it!!
My initial assumption about the reason for the error is correct. The clang-llvm environment was not available to the cppgrep tool, but I made the mistake in the way of providing the environment information to the cppgrep tool.
The answer has two steps: (1) change the Makefile to point the correct location where you have installed the llvm, in my case, I change the following line in Makefile from HEADERS := -isystem /llvm/include/ to HEADERS := -isystem /usr/lib/llvm-4.0/include/. (2) You have to compile the file again by using the make command, just enter an empty space and save the cppgrep.cpp file before giving the command, otherwise, you will get a message as make: Nothing to be done for 'all'..
That is it, now you should be able to run the cppgrep tool by running ./cppgrep 'x' test.cpp or ./cppgrep -help. For using the other tools in this docker such as ast-dump, mccabe, etc. you have to follow the same above two steps before using them.
I am trying got port FreeBSD on the ARMv8 foundation model.
I am following the wiki from [1]. But, I am not able to get past the step of building the tool chain.
a) According to step one, I could download all the binutils and it is in my home directory.
b) Next it is asking to change PATH of root Makefile. So I changed it as
**export PATH= $PATH:/aarch64-freebsd-sandbox/toolchain/build/aarch64-none-freebsd10/bin/**
c) Next, the step is to make kernel toolchain. But when I type
**make kernel-toolchain TARGET=arm64**
It gives an error saying
**make: *** No rule to make target `kernel-toolchain'. Stop.**
I did echo $PATH and found that the path is added correctly.
What might be the problem?
[1] https://wiki.freebsd.org/arm64
Thank you!
To do this, you have to start with a working FreeBSD system. Cross compiling from Linux won't work. If you are on FreeBSD 10, you can use the included svnlite, if you are on an earlier version, you need to install the /usr/ports/devel/subversion port.
First you need to build the binutils as described on the wiki.
Then you should download the branch that is mentioned on the wiki page. This branch should be installed at /usr/src (make a backup of the contents first in case you have to rebuil your current system!);
# mv /usr/src /usr/orig-src
# mkdir /usr/src
# svnlite co https://svn0.us-west.FreeBSD.org/base/projects/arm64 /usr/src
Then edit the Makefile in /usr/src to contain the path for the special binutils first. Otherwise the normal binaries for whatever architecture you're running will be found first, which will not work.
After then you can build the kernel toolchain;
# cd /usr/src
# make kernel-toolchain TARGET=arm64
# make _includes TARGET=arm64
Then you'll have to build the loader;
# make buildenv TARGET=arm64
This will open a new shell. From that shell you should run;
# make -C lib/libstand obj all
# make -C sys/boot -DWITHOUT_FORTH obj all
Don't exit that shell, because there is more. I assume that the kernel build procedure is more or less standard, it is not mentioned on the wiki;
# make buildkernel
This command needs to run in the shell that was opened by make buildenv.
Note: do not run make installkernel. That would presumably leave your x86 PC with an ARM kernel. :-)
The wiki doesn't mention building a userland, and it only shows the boot process, so I don't know if it even works.
You'll need a Linux box (or VM) to run the ARMv8 emulator. You will have to supply the kernel and boot loader that you built to this emulator, but I don't know how to do that. You definitly need to take that up on the freebsd-arm mailing list!
While trying to install a build server I've run into a funny problem where all cygwin commands can be run from a DOS box but sometimes do not work when called from make. What's even more weird is some make targets, like 'clean', work and others, like 'all', do not.
Here's a representative makefile extract. The quoting has hosed the formatting but tabs are where they should be, trust me:
.PHONY: all
all: update_autoconstants
/usr/bin/rm -f $(OBJ_DIR)/myfile1.txt
rm -f $(OBJ_DIR)/myfile2.txt
.PHONY: clean
clean:
rm -f $(OBJ_DIR)/*.*
Notice that in 'all' one rm call has a full path and one has no path. Also notice that clean's rm call has no path.
To this the response to a 'make -C makefile all' is:
/usr/bin/rm -f ../../obj/myfile1.txt
rm -f ../../obj/myfile2.txt
make: rm: Command not found
make: *** [all] Error 127
ie. the full path works, the no-path does not. What then starts my head spinning is the 'clean' target in make with no path works fine. it's not just cygwin commands, make can't find the compiler either. It seems pretty clear that somewhere the path has been hosed, although the environment variable PATH is set, but only in make - this works fine from a DOS prompt.
C:\>cygpath --unix c:\programme\cygwin\bin\rm
/usr/bin/rm
The machine is running Windows Server 2003 German language in a virtual machine on VMWare ESX, the cygwin install was done yesterday, installed in c:\programme\cygwin\ and everything else is clean vanilla Windows installation.
Any ideas? Thanks in advance.
Not really so much of a solution as a workaround - we made all the makefiles use absolute paths to the exe files they need which is in any case a bit nicer than searching a path and taking what you find.
To perhaps save someone some Googling commands in cygwin's bin directory can best be called:
CYGWIN_EXE_PATH = /usr/bin
RM = $(CYGWIN_EXE_PATH)/rm.exe
.PHONY: clean
clean:
$(RM) -f $(OBJ_DIR)/*.*
And similarly files in the program files directory like this:
COMPILER_DIR = "$(PROGRAMFILES)/TASKING/c563 v3.6r1"
Hope that helps.
I've had the exact same thing.
rm not being found by make from within a makefile.
My workaround was to run the makefile from within bash. Previously I was just running make from a windows cmd box. This cured the problem for me, but created new issues. The permissions of some files that were created during the make had very odd permissions being set.