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
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.
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 am running Arch Linux and trying to build a project in Qt however, Qt spits the following error:
/opt/cuda/include/crt/host_config.h:129: error: #error -- unsupported GNU version! gcc versions later than 7 are not supported!
I have already tried a suggestion from a previous Stack Overflow post found here:
CUDA incompatible with my gcc version
I did not use the exact command as my cuda is located in /opt/cuda/bin/gcc. I did the same command for g++. However, the terminal outputs that these files are already linked. I did confirm this by going to the actual file and looking at it's properties.
Can someone please suggest a solution to my issue?
I managed to do so usung this two lines, this will update the symbolic links of cuda to gcc7
ln -s /usr/bin/gcc-7 /usr/local/cuda/bin/gcc
ln -s /usr/bin/g++-7 /usr/local/cuda/bin/g++
The issue comes from cuda-10.0/targets/x86_64-linux/include/crt/host_config.h in the main CUDA-10 directory tree. The target for your architecture was placed in /opt.
Some posts recommend faking the inequality
if __GNUC__ > 7
to say
if __GNUC__ > 8
but that is a bad idea. Using
make 'NVCCFLAGS=-m64 -D__GNUC__=7' -k
is permissible in some trivial cases, but still fundamentally the same bad hack.
You probably have alternates on your system which has constructed symbolic links pointing to the version 8 gnu tool chain files. That's why you get an indication version 7 is already installed.
You can learn how to modify your alternates for just your developer users BUT NOT for root or any system admin accounts. You may want to remember how to switch back and forth between 7 and 8 so you only use 7 when actually needed, since many other things may be tested only with 8.
If that doesn't work for you, you can build gcc-7 from source. The preparatory system admin work includes a dnf install, a build from source, an install of 7.4 gnu compiler, and a set up of paths for CUDA development only. If you have gnu gcc and g++ version 8 installed with the appropriate standard libraries and it works, the version 7 compiler can be installed with relative ease.
Browse and find the nearest mirror listed on https://gcc.gnu.org/mirrors.html and then copy the link location for gcc-7.4.0.tar.xz and place it in the shell variable u like this example.
u="http://mirrors.concertpass.com/gcc/releases/gcc-7.4.0/gcc-7.4.0.tar.xz"
Then you can do the rest as commands.
sudo dnf install libmpc-devel
cd
mkdir -p scratch
cd scratch
wget -O - "$u" |tar Jxf -
cd gcc-7.4.0
mkdir build
cd build
../configure --prefix=/usr/local/gcc-7
make
sudo bash -c "cd \"`pwd`\"; make install"
Then you execute this in the shells and tools you develop with. Do NOT put this in the system login apparatus or in .bashrc or .bash_profile, for the same reason as above. Other things may be tested with version 8 only. Instead place them in your development environment where they belong.
LD_LIBRARY_PATH=/usr/local/gcc-7/lib64:$LD_LIBRARY_PATH
LD_LIBRARY_PATH=/usr/local/gcc-7/lib:$LD_LIBRARY_PATH
LD_LIBRARY_PATH=/usr/local/cuda-10.0/NsightCompute-1.0/host/linux-desktop-glibc_2_11_3-glx-x64/Plugins:$LD_LIBRARY_PATH
LD_LIBRARY_PATH=/usr/local/cuda-10.0/NsightCompute-1.0/target/linux-desktop-glibc_2_11_3-glx-x64:$LD_LIBRARY_PATH
LD_LIBRARY_PATH=/usr/local/cuda-10.0/targets/x86_64-linux/lib/stubs:$LD_LIBRARY_PATH
PATH=/usr/local/gcc-7/bin:$PATH
PATH=/usr/local/cuda-10.0/bin:$PATH
PATH=$HOME/big/cuda.samples/NVIDIA_CUDA-10.0_Samples/bin/x86_64/linux/release:$PATH
I've followed the instructions to install the stable branch of Virtuoso Open Source 7 on Ubuntu 16.04. There don't appear to be any errors throughout the process of —
./autogen.sh
CFLAGS="-O2 -m64"
export CFLAGS
./configure
make
make install
However, when I go to /usr/local/virtuoso-opensource/var/lib/virtuoso/db (which contains only virtuoso.ini) and run —
virtuoso-t -f &
The first time I do this the terminal just vanishes. When I reopen the terminal and run the same again it just reads The program 'virtuoso-t' is currently not installed. You can install it by typing: apt install virtuoso-opensource-6.1-bin.
I've tried installing both 7 stable and develop from github and both produce the same result. I'd rather use 7 but tried installing 6 via the ubuntu package and conductor wouldn't work for me - not having much luck all round, one of those days.
Thanks for assistance you can provide.
Sounds like you didn't adjust your $PATH variable after make install.
$PATH should include the path to the directory which contains the virtuoso-t, or you can include that path in the launch command, e.g. —
/path/to/virtuoso-t -f -c /usr/local/virtuoso-opensource/var/lib/virtuoso/db/virtuoso.ini &
(Note that the develop/7 branch is recommended over stable/7 at the moment, due to the number of fixes there.)
The readline library allows the CLI for sqlite to accept arrow keys to recall previously typed commands. I can build without this and sqlite works, it's just a hassle not having this nice capability. I've installed readline-devel from yum and /usr/lib64/libreadline.so.5 is present as well as it's header files. When I run ./configure to build sqlite, I see these lines:
checking for library containing readline... no
checking for readline... no
The library path is set to the correct path:
LD_LIBRARY_PATH="/usr/lib64:/usr/local/lib:/lib:/usr/lib"
By default, ./configure does try to include readline support so there are no special "--with-XXXX" options needed.
Anyone every seen this problem? I need to use this newer version to get latest foreign key support. It's hassle running on CentOS as is bundles pretty old versions of apps but we don't have a choice right now and I cannot find an updated RPM with newer version of sqlite.
=== UPDATE ===
Ok, I found a solution but I don't completely like it...
First, I tried with this option:
./configure CPPFLAGS="-I/usr/include/ -DHAVE_READLINE"
That causes the readline functionality to get compiled into shell.c which is what is needed for starters. But, the linking fails because it cannot find libreadline. The only 'kludgy' way I could figure out to get it to link was to manually edit the Makefile after running the above ./configure command. I changed this line:
LIBS = -ldl -lpthread
to this:
LIBS = -ldl -lpthread -lreadline -ltermcap
Then I ran "make clean all" and "make install" and the readline functionality works in the CLI.
I tried every way I could think of to pass in the extra libraries including exporting using LIBS, exporting using READLINE_LIBS, exporting using LDFLAGS, nothing would work. If you set LIBS to anything, like "export LIBS="-lreadline", it causes configure to fail. The --help on configure about using LIBS seems to contradict what happens when you actually set it to any value.
Anyway, this works so I can live with it - but I don't particularly like it! :(
==== THE RIGHT SOLUTION ====
Well, wouldn't you know it. Spend hours trying to figure it out, then stumble onto the right tip on Google. Just needed to install ncurses-devel first. So, to summarize all that is needed to built it 'unkludgily':
yum install ncurses ncurses-devel
yum install readline readline-devel
yum install libtermcap libtermcap-devel
./configure
make
make install
No special command line options or exports or Makefile edits needed! Readline support is automatically built in by default now.