So I'm trying to upgrade an old buildroot system, from 2018.08.x to the latest release. The issue is that upgrading from 2019.2.x to 2019.5.x or 2019.8.x generates an error while installing qt5virtualkeyboard 5.12.2.
Note: after revision 2019.2.x the Qt kits are updated from 5.11 to 5.12.
I've checked the package install.mk but there are no changes in the related lines:
ifdef QT5VIRTUALKEYBOARD_3RDPARTY_PARTS
define QT5VIRTUALKEYBOARD_INSTALL_TARGET_3RDPARTY_PARTS
cp -dpfr $(STAGING_DIR)/usr/qtvirtualkeyboard $(TARGET_DIR)/usr
endef
endif
and I've already tested that cleaning the qt5virtualkeyboard->language layouts and the qt5virtualkeyboard->handwriting resolve the issue.
Here's the make output from revision 2019.5.x:
qt5virtualkeyboard 5.12.2 Installing to target
mkdir -p /home/fg/work/acto/buildroot/output/target/usr/lib/qt/plugins/platforminputcontexts
cp -dpfr /home/fg/work/acto/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/qt/plugins/platforminputcontexts/libqtvirtualkeyboardplugin.so /home/fg/work/acto/buildroot/output/target/usr/lib/qt/plugins/platforminputcontexts
cp -dpf /home/fg/work/acto/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libQt5VirtualKeyboard*.so.* /home/fg/work/acto/buildroot/output/target/usr/lib
mkdir -p /home/fg/work/acto/buildroot/output/target/usr/qml/QtQuick
cp -dpfr /home/fg/work/acto/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/qml/QtQuick/VirtualKeyboard /home/fg/work/acto/buildroot/output/target/usr/qml/QtQuick/
cp -dpfr /home/fg/work/acto/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/qtvirtualkeyboard /home/fg/work/acto/buildroot/output/target/usr
cp: cannot stat '/home/fg/work/acto/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/qtvirtualkeyboard': No such file or directory
package/pkg-generic.mk:331: recipe for target '/home/fg/work/acto/buildroot/output/build/qt5virtualkeyboard-5.12.2/.stamp_target_installed' failed
make: *** [/home/fg/work/acto/buildroot/output/build/qt5virtualkeyboard-5.12.2/.stamp_target_installed] Error 1
At the moment I disabled the virtual keyboard configs to work on the system. But I would like to go deeper: I would like to understand if, during the update process, something went wrong, if I need to add some new dependencies packages or if this might be a package installation error.
Related
gmake doesn't seem to have a value for $(INSTALL). is this supposed to be defined by the user?
$(CC) works fine. most sample Makefiles i went over didn't have an explicit definition of $(INSTALL)...
if it has to be defined by user, what are best practices (other than aliasing _PROGRAM and _DATA)? why prefer install over cp?
Makefile
helloworld:
echo 'hello, world' >helloworld
install:
$(INSTALL) ${HOME}/ helloworld
log
$ make helloworld
$ make install
/home/<username>/ helloworld
make: /home/kevins/: Permission denied
make: *** [Makefile:5: install] Error 127
version info
GNU Make 4.3
Built for x86_64-pc-linux-gnu
There is no default value defined for INSTALL. You can see all the default rules and variables by running:
make -p -f/dev/null
Whether install or cp is a better fit depends entirely on your use-case. install does a lot more than cp. But, you can run other commands in addition to cp to take care of those things, and install is not available on every system. So, it's what's best for you.
I am desperated and hope someone might be able to bring some light on this problem:
I am trying to install netcdf-fortran in Fedora 35 using Intel compilers. To do so, I first installed ONEAPI from intel in /opt/intel/oneapi. Then, I install
https://gmplib.org/download/gmp/gmp-6.2.0.tar.lz
https://www.mpfr.org/mpfr-current/mpfr-4.1.0.tar.gz
https://ftp.gnu.org/gnu/mpc/mpc-1.2.1.tar.gz
git clone https://gnu.googlesource.com/gcc
git checkout releases/gcc-10
source /opt/intel/oneapi/setvars.sh intel64
export PATH=/opt/intel/oneapi/compiler/2021.4.0/linux/bin:$PATH
export LD_LIBRARY_PATH=/opt/intel/oneapi/compiler/2021.4.0/linu/lib:$LD_LIBRARY_PATH
export PKG_CONFIG_PATH=/opt/intel/oneapi/compiler/2021.4.0/lib/pkgconfig:$PKG_CONFIG_PATH
export C_INCLUDE_PATH=/opt/intel/oneapi/compiler/2021.4.0/linux/include:$C_INCLUDE_PATH
export CPLUS_INCLUDE_PATH=/opt/intel/oneapi/compiler/2021.4.0/linux/include:$CPLUS_INCLUDE_PATH
Then exported the utilities directory where I am install all these packages and exported it accordingly.
Then, I kept installing:
szip-2.1.1.tar
libjpeg-turbo-2.1.2
gzip-1.11
bzip2-1.0.8
libuuid-1.0.3
brotli
gperf-3.1
gettext-0.21
hdf-4.2.15
hdf5-1.13.0
netcdf-c-4.8.1
and up everything compiles and works fine. Yet, when I tried to install
https://downloads.unidata.ucar.edu/netcdf-fortran/4.5.3/netcdf-fortran-4.5.3.tar.gz
Then it keeps failing and failing with the error:
make[3]: * [Makefile:728: test-suite.log] Error 1
make[2]: * [Makefile:836: check-TESTS] Error 2
make[2]: Leaving directory '/SOME/LOCAL/ADDRESS/netcdf-fortran-4.5.0/nf03_test'
make[1]: * [Makefile:917: check-am] Error 2
make[1]: Leaving directory '/SOME/LOCAL/ADDRESS/netcdf-fortran-4.5.0/nf03_test'
I don't know what the problem is but it is not a problem with the version as even if I install an older version, the error keeps being the same.
I tried to follow the instructions I was finding about how to install these libraries.
Can someone please give me an advice on how to do this?
My configure is as follows:
CC=icc FC=ifort F77=ifort CPP="icc -E" ./configure --prefix=$PRFX --with-sysroot=$PRFX --with-pic
I have defined:
PRFX=/SOME/LOCAL/ADDRESS/
Thank you in advance,
When you say "... and up everything compiles and works fine." did you mean that you compiled all those packages with ONEAPI? or did you just install those from the depository?
It is much predictable to install netcdf-f when all other dependencies are compiled with a same compiler. Or you should refer to cross-compilation for all required dependencies.
Did you compile hdf5 and netcdf-c (which are one of the basic dependencies for netcdf-fortran) with the ONEAPI? If not, I recommend you doing that first.
I realized that using different compiler than GCC when compiling netcdf-fortran generates an error regarding shared library. You should try compiling it with static library by adding "--disable-shared --enable-static" during the "configuration" stage (for detailed instructions, consult the "Building with static libraries" sections of this link). Make sure you explicitly link the 'include' and 'lib'
directories when you are using the netcdf-f library.
I'm trying to compile glibc (CORRECTION: 2.34, not 2.3.4) on a RedHat system. I get this error while trying to run configure:
*** These critical programs are missing or too old: make compiler
*** Check the INSTALL file for required versions.
I installed the latest version of 'make':
> make --version
GNU Make 4.3
However, even with the latest version of 'make', I still get the same error. What is causing the problem?
glibc's configure prefers gnumake and gmake over make if they are available on the PATH command search path. Chances is that you have gmake binary that is version 3.81.
I think you should make with gcc version 6.5.0,
ct-ng may help you to build glibc. ct-ng http://crosstool-ng.github.io/docs/
1. ct-ng menuconfig
2. ct-ng build
You can choose gcc version at step 1.
As an reminder, glibc-2.34 remove some libs and no longer create like *-2.33.so under dir sysroot/lib/ . link:https://lwn.net/Articles/864920/
I ran into this issue as well and noticed that the config.txt was looking for gmake and found it in /usr/bin/gmake which was strange.
Listing shows that there is a symlink to make.
ls -l /usr/bin/gmake
lrwxrwxrwx. 1 root root 4 Jun 11 18:18 /usr/bin/gmake -> make
I installed make 4.3 in a custom path AND ensured that it was on $PATH but I was still getting the same error. Making a symlink to my custom installed version of make resolved the problem.
ln -s <custom path>/bin/make <custom path>/bin/gmake
Solved this by setting the MAKE variable. When looking in the configure script, it checks against "if test -n "$MAKE"; then", i.e.
MAKE=//make
export MAKE
Problem Definition
I'm attempting to adapt these rosjava installation instructions so that I can include rosjava on a target image built by the BitBake build system. I'm using the jethro branch of Poky.
Implementation Attempt: Build From .deb with package_deb.bbclass
According to the installation instructions, all that really needs to be done to install rosjava is the following:
sudo apt-get install ros-indigo-rosjava
Which works perfectly fine on my build machine. I figured that if I can just point to a .deb and use the Poky metadata class package_deb, it would do all the heavy lifting for me, so I produced the following simple recipe adapted on this posting on the Yocto Project mailing list:
inherit package_deb
SRC_URI = "http://packages.ros.org/ros/ubuntu/pool/main/r/ros-indigo-rosjava/ros-indigo-rosjava_0.2.1-0trusty-20160207-031808-0800_amd64.deb"
SRC_URI[md5sum] = "2020ccc8b4a67dd918a9a2c426eece0b"
SRC_URI[sha256sum] = "ab9493fabe1285b0d21aab031348d0d733d116b0b2470bae90025709b303b649"
The relevant part of the errors I get during the above recipe's do_unpack are:
| no entry data.tar.gz in archive
|
| gzip: stdin: unexpected end of file
| tar: This does not look like a tar archive
| tar: Exiting with failure status due to previous errors
| DEBUG: Python function base_do_unpack finished
| DEBUG: Python function do_unpack finished
The following command produces the output below:
$ ar t python-rosdistro_0.4.5-1_all.deb
debian-binary
control.tar.gz
data.tar.xz
You can see here that there's a data.tar.xz, not data.tar.gz. What can I do to remedy this error and install from this particular .deb?
I've included package_deb in my PACKAGE_CLASSES variable and package-management in my IMAGE_FEATURES. I've tried other methods of installation which have all failed; I thought this method in particular would be very useful to know how to implement.
Update - 3/22
I'm attempting to circumvent the problems with the method above by doing my installation through a ROOTFS_POSTPROCESS_COMMAND which I've adapted from forum posts like this
install_rosjava() {
${STAGING_BINDIR_NATIVE}/dpkg \
--root=${IMAGE_ROOTFS}/ \
--admindir=${IMAGE_ROOTFS}/var/lib/dpkg/ \
-L /var/cache/apt/archives/ros-indigo-rosjava_0.2.1-0trusty-20160207-031808-0800_amd64.deb
}
ROOTFS_POSTPROCESS_COMMAND += " install_rosjava() ; "
However, this fails due to dpkg not being a command found within the ${STAGING_BINDIR_NATIVE} path. The Yocto Project Reference Manual states that:
STAGING_BINDIR_NATIVE Specifies the path to the /usr/bin subdirectory of the sysroot directory for the build host.
Taking a look inside this directory yields a lot of commands but not dpkg (The recipe depends on the dpkg package, and this command can be found in my target rootfs after the build is finished; I've also tried pointing to ${IMAGE_ROOTFS}/usr/bin/dpkg which yields the same results). From what I understand of the BitBake process, this command may be in another sysroot, but I must admit that this is where my understanding breaks down.
Can I adjust this method so that it works, or will I need to start from scratch on an installation from source?
Perhaps there's a different method entirely which I could consider?
If you really want to install their deb directly then your rootfs postprocess is one solution. It doesn't work because depending on dpkg will build you a dpkg for the target but you want a dpkg that will run on the host. Add a dependency on dpkg-native to your image.
Though personally I'd either inherit bin_package and extract the deb they provide then re-package it as a standard package in OE, or ideally write a proper recipe to build rosjava and submit it to meta-ros (https://github.com/bmwcarit/meta-ros).
package_deb is where the packaging machinery for deb packages is stored, it's not something you'd inherit in a recipe but should be listed in PACKAGE_CLASSES.
When you put a .deb in a SRC_URI the fetcher will try to unpack it so you can access the contents: the assumption is that you're going to repack the contents as a native Yocto recipe.
If that's what you want to do then first you'll need to fix the unpack logic (in bitbake/lib/bb/fetch2/__init__.py) to handle .debs with xz-compressed data. This is a bug in bitbake and a bug report and/or patch would be appreciated.
The alternative would be to use their deb directly but I don't recommend that as it's likely the dependencies don't match. The best long-term solution would be to build it from source directly instead of attempting to use a package for another distro.
While installing libsigsegv for clisp, I have run into an error. "make install" does not finish correctly. The problem as I can see it is a permission issue. I am very new to Unix and cant figure out how to solve this issue. Can you help me please to solve this issue? Any suggestions highly appreciated.
me#me-VPCSB11FX:~/school/summer/libsigsegv/libsigsegv$ make install
Making install in src
make[1]: Entering directory `/home/me/school/summer/libsigsegv/libsigsegv/src'
make[2]: Entering directory `/home/me/school/summer/libsigsegv/libsigsegv/src'
test -z "/usr/local/lib" || /bin/mkdir -p "/usr/local/lib"
/bin/bash ../libtool --mode=install /usr/bin/install -c 'libsigsegv.la' '/usr/local/lib/libsigsegv.la'
/usr/bin/install -c .libs/libsigsegv.lai /usr/local/lib/libsigsegv.la
/usr/bin/install: cannot create regular file '/usr/local/lib/libsigsegv.la': Permission denied
make[2]: *** [install-libLTLIBRARIES] Error 1
make[2]: Leaving directory `/home/me/school/summer/libsigsegv/libsigsegv/src'
make[1]: *** [install-am] Error 2
make[1]: Leaving directory `/home/me/school/summer/libsigsegv/libsigsegv/src'
make: *** [install-recursive] Error 1
The installation step is trying to write to a shared directory /usr/local/lib, which is read-only for end users and writable only for administrators and such.
You would need to give yourself additional privilleges by using su or sudo -- see e.g. here.
Also please note that installing custom stuff this way of make install is not very nice nowadays. You should be using some package management system like RPM or Aptitude or whatever, depending on your Unix distribution. It handles uninstallation, dependencies, conflicts, updates and everything else automatically.
The detailed installation instructions are found in the INSTALL or INSTALL.generic file, for every GNU package. For GNU libiconv it is this file: http://git.savannah.gnu.org/gitweb/?p=libsigsegv.git;a=blob;f=INSTALL
The default installation location, /usr/local, is not writable by an ordinary user. You have three options:
Use sudo make install instead of make install.
Make the /usr/local directory and its subdirectory owned by yourself, instead of owned by root: chown -R $(id -u -n) /usr/local
Specify a different installation directory (see section "Installation Names" of said INSTALL file): For example: ./configure --prefix=${HOME}/gnu/arch/$(uname -p)