I have a simple Makefile. For some reason i is not importing PATH properly:
Here is what I get when I run echo $PATH in the terminal
/home/someuser/myfs/opt/pkg/petalinux-v2016.2-final/tools/common/petalinux/bin:/home/someuser/myfs/opt/pkg/petalinux-v2016.2-final/tools/linux-i386/petalinux/bin:/home/someuser/myfs/opt/pkg/petalinux-v2016.2-final/tools/common/petalinux/bin:/home/someuser/myfs/opt/pkg/petalinux-v2016.2-final/tools/linux-i386/microblaze-xilinx-elf/bin:/home/someuser/myfs/opt/pkg/petalinux-v2016.2-final/tools/linux-i386/microblazeel-xilinx-linux-gnu/bin:/home/someuser/myfs/opt/pkg/petalinux-v2016.2-final/tools/linux-i386/gcc-arm-none-eabi/bin:/home/someuser/myfs/opt/pkg/petalinux-v2016.2-final/tools/linux-i386/gcc-arm-linux-gnueabi/bin:/home/someuser/myfs/opt/pkg/petalinux-v2016.2-final/tools/linux-i386/aarch64-none-elf/bin:/home/someuser/myfs/opt/pkg/petalinux-v2016.2-final/tools/linux-i386/aarch64-linux-gnu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
Here is what I get for a PATH when I run make
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
Does anybody know what is going on?
Makefile is below and here is my system description
uname -a
4.4.0-72-generic #93~14.04.1-Ubuntu SMP Fri Mar 31 15:05:15 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty
Makefile
.PHONY: linux bootimage fsbl dts build-dts
all: linux bootimage
dts: build-dts package bootimage
rootfs: build-rootfs package bootimage
fsbl:
petalinux-build -c bootloader
clean:
echo $(PATH)
petalinux-build -x distclean
linux:
petalinux-build
build-dts:
petalinux-build -c device-tree
build-rootfs:
petalinux-build -c rootfs
package:
petalinux-build -x package
bootimage:
petalinux-package --boot --force --fsbl ${BOOT_FSBL_IMAGE} --fpga ${BOOT_BIT_IMAGE} --u-boot=${BOOT_UBOOT_IMAGE} -o ${BOOT_IMAGE}
Here is what I get for a PATH when I run make
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
Here your make file dont have necessary path file that needed for your programm to run.
Easiest way to do export is like this in the makefile.
export PATH := bin:$(PATH)
Perhaps, something like this.
export PATH := $(shell pwd)/bin:$(PATH)
target:
mkdir -p ./bin
export PATH
echo $(PATH)
or another approach is to export all the path variable add that to your ~/.bashrc, its done, it sets explicitly.
You can append more path using ":" ,add this line in your ~/.bashrc
export PATH=$PATH:~/your/bin1:~/your/bin2
sample example appending more path in env path :
export PATH=/opt/bin:/usr/local/bin:/usr/contrib/bin:/bin:/usr/bin:/usr/sbin:/usr/bin/X11
Information about export:
Related
Installed kernel-devel with yum on CentOS, Why missing some source codes in some sub-directories (such as fs/fuse) ?
$ uname -r
4.18.0-348.el8.x86_64
$ ls /usr/src/kernels/4.18.0-348.2.1.el8_5.x86_64/fs/fuse/
Kconfig Makefile
$ uname -r
4.18.0-348.el8.x86_64
$ ls /usr/src/kernels/4.18.0-348.2.1.el8_5.x86_64/fs/fuse/
Kconfig Makefile
It is expected as here: https://github.com/torvalds/linux/tree/v4.18/fs/fuse
Kconfig
Makefile
acl.c
control.c
cuse.c
dev.c
dir.c
file.c
fuse_i.h
inode.c
xattr.c
I want to build a rpm package from a spec file(hello-world.spec).The command and error output are given below
Command1:
rpmbuild -ba hello-world.spec
ErrorOutput1:
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.z4GoQn
+ umask 022
+ cd /root/rpmbuild/BUILD
+
: not foundm-tmp.z4GoQn: 28: /var/tmp/rpm-tmp.z4GoQn:
error: Bad exit status from /var/tmp/rpm-tmp.z4GoQn (%prep)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.z4GoQn (%prep)
Content of my spec file is
Name: hello-world
Version: 1
Release: 1
Summary: Most simple RPM package
License: FIXME
%description
This is my first RPM package, which does nothing.
%prep
# we have no source, so nothing here
%build
cat > hello-world.sh <<EOF
#!/usr/bin/bash
echo Hello world
EOF
%install
mkdir -p %{buildroot}/usr/bin/
install -m 755 hello-world.sh %{buildroot}/usr/bin/hello-world.sh
%files
/usr/bin/hello-world.sh
%changelog
# let's skip this for now
My System/software details are
OS: Ubuntu 16.04
RPM version:4.12.0.1
The list of contents in rpmbuild folder is
Command2:
:~/rpmbuild# ls
Output2:
BUILD BUILDROOT RPMS SOURCES SPECS SRPMS
Can anybody help on this issue?
Check how your files is being generated. If you are passing files from windows to Linux, usually, there are different EOL for the files. We had a similar issue, I recommend you to change all the files to Unix format. I'm sharing with you how to reproduce your issue, if you edit that file in a Linux environment, like "nano", the problem disappears.
The server manager told me they updated/built vim to the latest version at /opt/vim/src/vim but when I open $vim, it is still the old version. Then I check:
$which vim
/usr/bin/vim
My question is how to set or change $PATH so that I will initiate the latest vim version?
Here is the OS information:
~$ uname -a
Linux ccis4301 3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8 21:10:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.5 LTS"
In your .bashrc or .zshrc set:
export PATH="/opt/vim/src:$PATH"
PATH holds the lists of dirs which are searched for binaries in order one by one. Hence, the order is important.
export PATH=$PATH:/opt/vim/src
will result in picking /usr/bin/vim.
We can override this by flipping the order
export PATH=/opt/vim/src:$PATH
and to make it permanent. Add this to your rc file like ~/.bashrc
echo 'export PATH=/opt/vim/src:$PATH' >> ~/.bashrc
source ~/.bashrc
I try to use an executable script (wkhtmltopdf) on a Linux shared webserver (Debian, 64bit). I am pretty sure that I compiled everything correct, but whenever I want to execute the file I get as an response :
> ./wkhtmltopdf -H
-bash: ./wkhtmltopdf: No such file or directory
To be sure that the file is there, here the ls output :
> ls
wkhtmltoimage wkhtmltopdf
Furthermore I tested the file command on it, which outputs the following :
> file wkhtmltopdf
wkhtmltopdf: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
My question is now :
Why does bash tells me that there is no 'file or directory', when there obviously is one?
My first guess would be that the shared server does not allow to execute binary files? But shouldn't it then be a problem of permissions, with a different bash output?
Edit :
> id
uid=2725674(p8907906) gid=600(ftpusers) groups=600(ftpusers)
> ls -l wkhtmltopdf
-rwxrwxrwx 1 p8907906 ftpusers 39745960 Jan 20 09:33 wkhtmltopdf
> ls -ld
drwx---r-x 2 p8907906 ftpusers 44 Jan 28 21:02 .
I bet you miss dynamic linker. Just do a
readelf --all ./wkhtmltopdf | grep interpreter
You should get an output like this:
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
There are high chances that you system lacks the interpreter (/lib64/ld-linux-x86-64.so.2 in the example). In this case bash would yell No such file or directory, just like when the binary itself is missing.
You can try to use a different linker. Sometime you can succeed. Just do a:
/path/to/the/linker /path/to/your/executable
This command:
find /lib* -name ld-linux\*
will help you find the linkers on your system. Or you can do the readelf command on some command that does run. It will show you correct, working linker.
OR, since you are running Debian system, just do a
sudo apt-get install wkhtmltopdf
to install native version of the tool :)
In my case
$ readelf --all ./wkhtmltopdf | grep interpreter # readelf: Displays information about ELF files.
[Requesting program interpreter: /lib/ld-linux.so.2]
On a machine where the executable was working:
$ ls -lah /lib/ld-linux.so.2
lrwxrwxrwx 1 root root 25 Apr 16 2018 /lib/ld-linux.so.2 -> i386-linux-gnu/ld-2.27.so
$ dpkg -S /lib/ld-linux.so.2 # -S, --search filename-search-pattern: Search for a filename from installed packages.
libc6:i386: /lib/ld-linux.so.2
So to fix the problem (reference)
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install libc6:i386 # GNU C Library: Shared libraries (from apt show)
Missing the linker was my case as well. I could fix it with the help of nsilent22 answer like this:
readelf --all /usr/local/myprogram | grep interpreter
[Requesting program interpreter: /lib64/ld-lsb-x86-64.so.3]
But that linker did not exist anymore.
The old situation in /lib64 was:
ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.31.so
ld-linux-x86-64.so.3 -> ld-linux-x86-64.so.2
So it turned out this was just a symlink to the systems' linker.
Moving over to /lib64 , which itself is a symlink to usr/lib64 and creating a symlink over there did not work. I assume that there are to many symbolic link levels after Debian moved everything into /usr
However creating a 'direct' symlink
ln -s /usr/lib64/ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so.3
did the job; /usr/lib64 now shows:
ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.31.so
ld-lsb-x86-64.so.3 -> /usr/lib64/ld-linux-x86-64.so.2
I ran into this issue on my raspberry pi 4 running aarch64 alpine 3.13. Using the answer provided by #vkersten, I was able to determine that I was missing /lib/ld-linux-aarch64.so.1.
I resolved this by installing gcompat with apk add gcompat.
I am trying to add my own program to a small linux, created with Buildroot.
What I've done so far:
I've created a new directory inside my 'buildroot/package/' called 'HelloWorld'.
Inside 'buildroot/package/HelloWorld' I have : a Config.in, HelloWorld.mk and HelloWorld directory.
Config.in holds this:
config BR2_PACKAGE_HELLOWORLD
bool "helloworld"
default y
help
Hello world component.
HelloWorld.mk holds this:
HELLOWORLD_VERSION:= 1.0.0
HELLOWORLD_SITE:= /home/userpc/Downloads/helloworld/
HELLOWORLD_SITE_METHOD:=local
HELLOWORLD_INSTALL_TARGET:=YES
define HELLOWORLD_BUILD_CMDS
$(MAKE) CC="$(TARGET_CC)" LD="$(TARGET_LD)" -C $(#D) all
endef
define HELLOWORLD_INSTALL_TARGET_CMDS
$(INSTALL) -D -m 0755 $(#D)/helloworld $(TARGET_DIR)/bin
endef
define HELLOWORLD_PERMISSIONS
/bin/helloworld f 4755 0 0 - - - - -
endef
$(eval $(generic-package))
(inspiration source)
The HelloWorld directory contains: main.c & Makefile:
main.c :
#include <stdio.h>
int main()
{
printf("\nMain entry.\n");
return 0;
}
Makefile:
CC=gcc
CFLAGS=-I.
all: *.c
$(CC) -Os -Wall *.c -o helloworld
# $(STRIP) helloworld
clean:
rm -f a.out helloworld
rm -f *.o
Edit: And I have also added source "package/HelloWorld/Config.in" to 'package/Config.in'
But when I mount my rootfs.ext2 partition I can't find my HelloWorld executable inside /usr/bin .., I am really new to this and don't have any prior knowledge, so could you please explain to me, what am I missing from this, because I'm sure I'm doing something wrong.
UPDATE: The program builds and install at the desired location but when I try to run it like so: ./helloworld, I get: bash: ./helloworld: No such file or directory It has execution rights. What is the matter with it? (I try to run it after I mount the rootfs.ext2 into a ubuntu directory, the target arch for buildroot is i386, so it should be ok, right?)
After building and installing the HelloWorld program, and eventually running it, I'd like to add to init.d so it starts after booting, and replace the HelloWorld with a Qt Window that doesn't need a X server, like this thing here.
The main source of inspiration here.
Minimal tested example on top of 2016.05
GitHub upstream:
https://github.com/cirosantilli/buildroot/tree/in-tree-package-2016.05
This example adds the package source in-tree, which is simple for educational purposes and the way to go if you want to merge back (kudos!),
If you do not intend on merging back (booooh!), it is more likely that you will want to use Buildroot as a git submodule and either:
an out of tree package with BR2_EXTERNAL as shown at: https://github.com/cirosantilli/buildroot/tree/out-of-tree-2016.05
*_OVERRIDE_SRCDIR + other git submodules as explained at: How to modify the source of Buildroot packages for package development?
Files modified:
package/Config.in
menu "Misc"
source "package/hello/Config.in"
endmenu
package/hello/Config.in
config BR2_PACKAGE_HELLO
bool "hello"
help
Hello world package.
http://example.com
package/hello/hello.mk
################################################################################
#
# hello
#
################################################################################
HELLO_VERSION = 1.0
HELLO_SITE = ./package/hello/src
HELLO_SITE_METHOD = local
define HELLO_BUILD_CMDS
$(MAKE) CC="$(TARGET_CC)" LD="$(TARGET_LD)" -C $(#D)
endef
define HELLO_INSTALL_TARGET_CMDS
$(INSTALL) -D -m 0755 $(#D)/hello $(TARGET_DIR)/usr/bin
endef
$(eval $(generic-package))
package/hello/src/.gitignore
hello
package/hello/src/Makefile
CC = gcc
.PHONY: clean
hello: hello.c
$(CC) -o '$#' '$<'
clean:
rm hello
package/hello/src/hello.c
#include <stdio.h>
int main(void) {
puts("hello");
}
Usage:
make qemu_x86_64_defconfig
echo 'BR2_PACKAGE_HELLO=y' >> .config
make BR2_JLEVEL=2
qemu-system-x86_64 -M pc -kernel output/images/bzImage -drive file=output/images/rootfs.ext2,if=virtio,format=raw -append root=/dev/vda -net nic,model=virtio -net user
From inside qemu:
hello
Expected output:
hello
Tested in Ubuntu 16.04.
In general, the sources for buildroot packages are taken from a (downloaded) tarball. What you are doing right now (placing the sources inside package/HelloWorld) is not the right way to proceed.
Buildroot does have provisions for 'local' package sources, which you could use if you really need to. You'll need the HELLOWORLD_SITE_METHOD variable for that.
Please refer to http://buildroot.uclibc.org/downloads/manual/manual.html#adding-packages for more information.
Also, you don't need to define HELLOWORLD_DIR, HELLOWORLD_BINARY, HELLOWORLD_TARGET_BINARY.
Update: regarding your additional question:
UPDATE: The program builds and install at the desired location but when I try to run it
like so: ./helloworld, I get: bash: ./helloworld: No such file or directory, it has
execution rights.. what is the matter with it? (I try to run it after I mount the
rootfs.ext2 into a ubuntu directory, the target arch for buildroot is i368, so it should
be ok, right?)
No, it does not work like that. You can't just mount rootfs.ext2 and expect to run programs from it. This is, among others, because the programs inside rootfs.ext2 are compiled against the libraries also inside rootfs.ext2, but if you run it like that it will use the libraries in /usr/lib. You either have to boot your system entirely with the rootfs.ext2, use qemu, or use a chroot environment. For chroot, you should use the 'tar' filesystem format, not ext2. See also here:
http://buildroot.uclibc.org/downloads/manual/manual.html#_chroot