the CentOS documentation says my new kernel will be in the
rpmbuild/RPMS/`uname -m`/ directory, but the RPMS directory is totally empty, even though the rpmbuild ended with exit 0.
The command I used was:
rpmbuild -bp --target=$(uname -m) kernel.spec
PS. (arch=s390x)
Can someone tell me what I am doing wrong?
-bp option only completes the %prep stage. Try changing it to -ba to "build all."
Ref: rpm.org
Related
I am just learning C++ via Codelite, which was updated on 01/11. After updating to the latest version, 17.0.0, I get the error
process_begin: CreateProcess(NULL, makedir Debug, ...) failed.
mingw32-make[1]: *** [AssignmentOperator.mk:90: Debug/.d] Error 2,
mingw32-make: *** [Makefile:5: All] Error 2
when I run a simple code.
#include <iostream>
int main(){
std::cout<<"Hello"<<std::endl;
return 0;
}
and get nothing in the terminal window.
How can I fix this problem? Thanks a lot.
I guess the probrem occured since the updating of Codelite, but I have no idea how to fix it.
Looks like a an old relic that was not handled properly during upgrade.
This can be fixed in 2 ways:
Update the mkdir command as defined by your compiler setup:
Go to Settings -> build settings and select your compiler from the list
Select the Tools tab
Select the last entry at the bottom mkdir
Replace the content with the mkdir that comes with CodeLite, for example, if you have installed CodeLite under C:\Program Files\CodeLite (the default path), set it to
"C:/Program Files/CodeLite/mkdir.exe" -p
Notice the double quotes around the command itself
Change the makefile generator used
Right click on your project and open the project settings
In the General tab, under the Makefile Generator change the selection from Default -> CodeLite Makefile Generator
I'm using Mac OS 13.1, and codelite 17.0.0, and when I 'clean', build completed successfully. But when I run its show 'make: ***[All] Error 2.
What happened? just new to learn C++
I had the same problem with Codelite 17 in windows.
Solution:
In Settings - Build - Tools under Makedir select the Path of mkdir.exe within in the Codelite folder (surrounded by " -quotes).
Although context help says to leave it empty in order to use the OS' own mkdir, Windows' mkdir is quite different to the mkdir of other *ix-like OS.
Furthermore for me it was necessary to explicitly add -p
There is a hint in Codelite's change dokumentation in the recent monthly build 17.1 that it solves this problem as a bugfix.
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
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.
I'm installing Apache Spark which uses its own copy of SBT to set things up.
I'm using Linux Mint in a VirtualBox VM.
Here's a snippet from the error when I run sudo ./sbt/sbt compile from the Spark directory spark-0.9.0-incubating:
[error] (core/compile:compile) java.io.IOException: Cannot run program "javac": error=2, No such file or directory
[error] Total time: 181 s, completed Mar 9, 2014 12:48:03 PM
I can run java and javac from the command line just fine: e.g. javac -version gives javac 1.6.0_31
The correct jdk1.6.0_31/bin is in my PATH.
I read that the error might be due to the 64-bit JDK that I had installed, but I get the same error with the 32 bit JDK.
How can I sort out the issue?
edit: Using bash shell.
DISCLAIMER I'm mostly guessing now and still am unsure I should've responding here rather than adding a comment. Until it's clear, the DISCLAIMER remains.
When you execute java and javac from the command line, what user are you at that moment? I'm pretty sure your problems surface because the users you operate are different.
Please notice that you're executing sudo ./sbt/sbt compile as root (due to the way sudo works), but you say nothing about what user(s) you've been using to execute javac and java commands.
Add jdk1.6.0_31/bin to PATH for root and you'll be all set (as far as the configuration of Java's concerned).
I'd also recommend setting JAVA_HOME to point to jdk1.6.0_31 as it may help at times -- many applications are using it as the way to find the location of Java.
As a workaround, you may edit ./sbt/sbt and add PATH and JAVA_HOME appropriately.
You need to include the javac executable. To do this in Ubuntu please run the following command:
sudo apt-get install openjdk-7-jdk
It also places it within your path variable.
I'm using the tar command in UNIX to perform backups of particular directories. However, some directories contain files/sub-directories which the current user doesn't have any read permissions on. As a result the tar command is returning a non 0 exit code.
I came across the following modifier in the man pages '--ignore-failed-read', which suppresses the non 0 exit code when encountering files it cannot read. However, whenever I try using it I get the error 'unknown function modifier'.
Could anyone help me out here?
my tar command looks something like this:
tar --create --ignore-failed-read --file=test.tar my_dir
Your command seems to be perfectly valid and I don't see any typos/mistakes.
To be absolutely sure, I just tried it on my VM running under 32 bit Debian 7.1 (wheezy) with stock kernel 3.2.0.4. As I suspected, archive has been created successfuly (the only change was, of course, the name of the source directory). I also checked version of my tar with
tar --version
which gave me following output:
tar (GNU tar) 1.26
First of all, you should check this info. If you get the same (with possible difference in version number) output, that's fine. If not (or version that seems much older), it's possible, that you are using tar, which simply doesn't support this feature.
Also, you can check, if your tar really DOES support mentioned flag. To do this, type into console:
tar --help | grep ignore-failed-read
You should see something like this:
--ignore-failed-read do not exit with nonzero on unreadable files
If output stays empty, that means this version of tar does not know this flag at all.
See if any of the above helps.
Another option that might work better in this case is --warning=no-file-changed.
tar --warning=no-file-changed -czf backup.tgz dir1 dir2
--warning controls the display of warning messages. You can add no- to the message keyword to suppress it. So in this case no-file-changed suppresses the file-changed warning.
c.f. https://www.gnu.org/software/tar/manual/html_section/tar_27.html