I built the parallel version of HDF5. Then I tried to build FLANN through cmake-gui.
Since the HDF5_DIR was signed as HDF5_DIR-NOTFOUND I tried with sudo apt-get install libhdf5-mpi-dev (I have already installed mpicc), but nothing changed.
I think that if this entry will not change then I'll problems the make phase (especially because I want to execute FLANN in parallel with MPI and OpenMP).
Related
Requires: in the spec files sets the package dependencies, but what will happen if the repo of the requirements is not in the repolist?
Is there a way to use pre downloaded rpm files and tell the rpmbuild that the dependencies should be installed from the local file like yum localinstall.
You're conflating rpm and yum when you mention repolist.
rpm is a lower level and only knows about RPM files
yum collects sets of RPMs into repositories and sits on top of RPM to handle dependencies
Now, to answer the question - rpmbuild does not need anything from the Requires field to build the RPM. If it does, then the RPMs should be listed as BuildRequires in the specfile and only be in Requires if the end user needs it to be installed to run the final product. For example, to build you might need foo-devel but at runtime you only need libfoo. Those should be declared appropriately.
Even if you fix the Requires vs. BuildRequires fields, it still won't help you - rpmbuild cannot install RPMs itself because you should never run rpmbuild as root. An error in a specfile can very easily nuke an entire machine if it's run as root.
I'm trying to install omnetpp 5.2.1 on windows 10. But getting an error while doing ./configure command related to QT environment. I tried changing the configure.user file in omnetpp package to change the path of QT but still its not working. Here is the error:
configure:error: Qtenv cannot find qmake--maybe it is not in the path
or has some exotic name (tested names were: qmake qmake-qt5 qmake5)-
disabling Qtenv. You can try setting QT_PATH variable in
configure.user to a valid location.
qt5 might not be installed.
sudo apt install qt5-default worked for me while installing on Ubuntu 20.04.
OMNeT++ comes with all dependencies bundled. As long as you have executed the mingwenv.cmd and running from that shell, qmake should be available in the path (in tools/win64/mingw64/bin). Check if qmake.exe is present there. If not, make sure that ZIP file you have downloaded is intact. Standard windows unzip may fail on certain systems...
run ./configure WITH_QTENV = no
I've been trying to install tensorflow with GPU support using these steps:
http://www.nvidia.com/object/gpu-accelerated-applications-tensorflow-installation.html
and also using:
http://thelazylog.com/install-tensorflow-with-gpu-support-on-sandbox-redhat/
This is the error message that I'm getting when I try to run the bazel build command for building the tensorflow pip package (with the --config-cuda flag set):
The specified --crosstool_top '//third_party/gpus/crosstool:crosstool' is not a valid cc_toolchain_suite rule.
What's strange is that if i remove the --config=cuda flag, I don't get the error message while building and I'm able to install tensorflow successfully - but without GPU support.
I experienced the same issue, using the nvidia instructions. What I did was to drop the git reset line in the instructions, and it works.
Details (from the error message):
Close, reopen terminal
Run git clone (again), and cd tensorflow
Run ./configure
Bazel build, etc
This may be unrelated, but I experienced an issue with the .whl line, the error message was that the wheel cannot be found or something along those lines. This is the "And finally install the TensorFlow pip package" section. To resolve it in my case, I typed in the terminal all the way to "..._pkg/tensorflow", and then pressed tab for auto-completion. The file name that popped up was significantly longer than that in the guide, but it worked. Also, if anyone face a numpy not installed message based on the nvidia instructions, replace the python-pip and dev with python-numpy and run that line again to install.
Configuration: Fresh Ubuntu 16.04, GTX970M, running driver 367.48 (from CUDA installation), CUDA 8.0, CuDNN 5.1
Full setup path:
Fresh Ubuntu, with downloads and 3rd party apps selected during installation.
Control panel => Software and updates => Other Software => Canonical ticked
Install CUDA using nvidia instructions in CUDA documentation, .deb format
CuDNN 5.1 installed, the rest from the nvidia link.
I hope everything works out for you!
(I'm sorry for the poor formatting)
I was going through same problem and recently found the solution. The problem is with the installation of Bazel which leads to this kind of error.
After installation of bazel from installer, make sure that you would give the correct path to ~./bashrc and also activate the path using
source "path-to-your-bin-directory-for-bazel"
Please change the git source version slightly as shown below
$ git clone https://github.com/tensorflow/tensorflow
$ cd tensorflow
// $ git reset --hard 70de76e
$ git reset --hard 287db3a
And please refer the below l
https://github.com/tensorflow/tensorflow/issues/4944
Also, zlib has been updated since this TF build. You need to check http://www.zlib.net/ to get the latest version and SHA-256, then update tensorflow/workspace.bzl with that information (lines 254-266 in this build). At this time, the correct version info would include the following:
url = "http://zlib.net/zlib-1.2.11.tar.gz",
sha256 = "c3e5e9fdd5004dcb542feda5ee4f0ff0744628baf8ed2dd5d66f8ca1197cb1a1",
strip_prefix = "zlib-1.2.11",
The fact
I have got metis 5.1.0 installed on a desktop running on Ubuntu 12.04 LTS.
Recently I compiled a piece of software in parallel configuration that could not find the file /opt/metis/metis-5.1.0/lib/libmetis.a and threw a fatal error.
This looks weird to me because all was fine with an earlier version of the same software and with the existing metis installation.
Disappearance of libmetis.a
I have evidence that libmetis.a had been installed, though, from the stderr+stout files of the first metis installation.
For example from somewhere in the output of make install I can see:
/usr/bin/cmake -P cmake_install.cmake
-- Install configuration: ""
-- Installing: /opt/metis/metis-5.1.0/include/metis.h
-- Installing: /opt/metis/metis-5.1.0/lib/libmetis.a
-- Installing: /opt/metis/metis-5.1.0/bin/gpmetis
Therefore some action must have deleted libmetis.a at some point.
I have no recollection or clue of which action could have done this.
Reinstallation of metis
I then reinstalled the same version of metis by running the very same script that I used the first time. The procedure is
sudo make uninstall
sudo make clean
sudo make config prefix=/opt/metis/metis-5.1.0 shared=1 cc=gcc gdb=1 debug=1
sudo make
sudo make install
The corresponding lines in the stdout+sterr have changed though
/usr/local/bin/cmake -P cmake_install.cmake
-- Install configuration: ""
-- Installing: /opt/metis/metis-5.1.0/include/metis.h
-- Installing: /opt/metis/metis-5.1.0/lib/libmetis.so
-- Installing: /opt/metis/metis-5.1.0/bin/gpmetis
Comparison
cmake lives on another path. I can't recall a reason for this. I do confirm that currently cmake is installed in /usr/local/bin/cmake and that /usr/bin/cmake does not exist any longer. Either way, the version of cmake has been 3.3.1 ever since (I believe).
libmetis.so gets installed instead of libmetis.a.
Comparing the old and new stderr+stdout of the make install line by line, I see that cmake has been engaged in the first installation a great deal more. Unfortunately I have overwritten the files of the first installation and cannot provide more detail.
Summary
To summarize the changes I noted are
the static library libmetis.a disappeared (blind spot why/how/when)
cmake is displaced (blind splot why/how/when)
a copycat installation of metis leads to shared-object library libmetis.so rather than libmetis.a, perhaps after a different usage of cmake. I look at that shared=1 in the config command suspiciously, but had worked with scripts with an intention to repeat all operations faithfully. (Though not always are good intentions coded down correctly.)
The aim is to have the libmetis.a file in place again, as requested by parallel software down the line.
Any suggestions tips and pieces of wisdom to fix this issue? Thanks in advance for thinking along.
Our project uses autoconf/automake for configuring and building. The building scripts work fine on Debian Squeeze and Wheezy (automake version 1.11.6), but don't work on Jessie, with a more recent version of automake (version 1.14.1). When I run make distcheck with the new automake version, it fails with
make[3]: Entering directory `/tmp/.../_build'
/bin/bash: ../autotools/test-driver: No such file or directory
Apparently, test-driver is a new script introduced by the recent automake version.
I tried to add autotools/test-driver into extra dependencies, but if it's present, distcheck fails with
.../_build/../autotools/test-driver: the following mandatory options are missing:
--test-name --log-file --trs-file
I'd appreciate any ideas how I could either update my build scripts to work with the new version or how to disable this new automake behavior.
Run automake -a at the top-level. Usually you should have a bootstrap script that invokes autotools with the correct flags for clean repository checkouts, or for when you make drastic changes to your build system.
And there's no need to set dependencies, unless you are custom-generating test-driver from a template or something.