I'm using Redhawk v1.10 and uploaded the integration redhawk components to the target sdr.
I get the following error when I attempt to launch any of the uploaded gnuhawk components to the target sdr:
Failed to launch "component name" Unable to load software package 'deps/gnuhawk/gnuhawk.spdml'(dependency of software package 'component name', implementation 'cpp')
Although the components haven't been updated for 1.10, they should still be compatible.
Here are two options you could try:
1) Make sure your GPP is running if you are launching the component to an active domain.
2) Open up a terminal window, go into the component directory and run $ ./build.sh this should generate a new file that you can move into the cpp folder. It should be called .cpp. For some reason, RH isn't picking up the old cpp files but will pick up these new files. It's worth a shot.
Let me know if either of those work.
There are two steps to installing the GNUHAWK components from source: compiling/installing the GNUHAWK soft package dependency and compiling/installing the individual components. Your error implies that the first step was not completed.
First, you will need a few dependencies:
# yum install orc-devel gsl-devel python-cheetah cmake
Second, compile and install the GNUHAWK soft package dependency. This will take a while to complete.
Navigate to the top-level GNUHAWK source code directory.
Run these commands:
$ ./reconf; ./configure; make -j8 ; sudo make install
Third, compile and install the GNUHAWK components. This will also take a while to complete.
Navigate to the components directory
$ cd components
Run these commands
$ ./reconf; ./configure; make -j8 ; sudo make install
To make things run a little faster, you can try running more than 8 compile jobs (e.g., "make -j16"); however, setting the number of jobs too high (i.e., unlimited: "make -j") can lock up your machine due to the large number of components that will be built in parallel.
Related
I have completed a small project that uses several libraries. the CMakeList.txt looks like this:
cmake_minimum_required(VERSION 3.5)
project(tf_ct_log C)
set(CMAKE_C_STANDARD 99)
include_directories(include /usr/local/include/hiredis /usr/include/openssl)
link_directories(/usr/lib/x86_64-linux-gnu)
set(HDR include/ct_logger.h)
add_executable(tf_ct_logger src/main.c src/ct_logger.c ${HDR})
find_package(OpenSSL REQUIRED)
find_package(Threads REQUIRED)
find_library(PostgreSQL REQUIRED)
find_library(jansson REQUIRED)
target_link_libraries(tf_ct_logger OpenSSL::SSL jansson pthread pq)
I would like to be able to build a package that can be installed in another machine, without downloading any dependencies. with ldd, I 've got all dependencies of the application and copied those files (libxyz.so...) into a subdirectory deps in my project. How can I create that package using those dependencies so that the end user will just use the object files of my project along with the dependencies libraries to create the executable?
It gets really hairy real quick when you need to create a native package for multiple flavors of installers (Debian, RH, Arch, etc.), especially if customization is involved.
If you just need a clean reproducible to get it on a box and run -- I would strongly suggest looking towards packaging it as a Docker container.
You start from some lightweight Linux distro container (Alpine is the latest trend), derive it into one with C and C++ runtime and anything else you depend on and call this "my prod container". From that you derive one with C++ compiler and debugger installed and call it "my dev container".
We actually wrote a little memo a while back, while making our open source hobby usable for others.
You will probably still need to clean up your CMake file to an extent that the "install" target works (mine is here).
I may have not expressed myself correctly. I just wanted to compile and build executables from my project, then find a way to copy it on another machine without having to install all dependencies before running the app.
The solution I found (with the help of a more experienced developer) was as follows:
1- Get all dependencies using ldd
2- Copy dependencies in a directory dependencies
3- On the target environment, copy content of dependencies into /usr/local/lib/myapp/
4- On the target environment, goto /etc/ld.so.conf.d/
5- create the file myapp.conf with one line in it: /usr/local/lib/myapp
6- run ldconfig
Then, the executable I created on my development machine runs here smoothly!
Of course all the steps I described up there must be listed in a script for automation
I'm trying to install dkms onto machines that have no make or gcc.
I plan to push only binaries to those target machines.
On my build machine I plan to use dkms to build dkms-enabled modules and then use dkms mktarball ... --binaries-only to create tarballs for distribution.
I want to push those tarballs to target machines, and on those machines I
want to use dkms ldtarball, and so the target machines do need dkms,
but they don't need gcc (or make).
Build (host) and target machines run the same Ubuntu
apt-get install dkms on the target automatically brings in gcc
Downloading the dkms.deb (apt-get download dkms)and installing it with dpkg --install --ignore-depends=gcc ... dkms.deb
does work, but leaves the dependency unresolved so that any future apt-get (installing some other package for instance) fails.
I can try to use the equiv package to create dummy installations of gcc and make, but this seems like an awful hack I'd prefer to avoid. Also it could create problems if I ever want to actually install
gcc on the target in the future.
There's a note about this in the dkms README (section 3), but no guidance on how to accomplish it.
"If you choose not to load module source on your system or if you choose not to load a
compiler ... DKMS can still be used to install modules.".
(sorry if the tags are misleading ... there's no tag available for dkms)
Create a local dummy package which pretends to install gcc and any other deps you want to keep off your system. The equivs package can be used for this, but it's simple enough to do by hand as well.
Many thanks to Darik Horn for an excellent (offline) answer.
He suggested using /etc/apt/preferences.d to pin the unwanted packages. That solution looks promising and I will explore further (and post results here if possible).
I was able to find another solution Ubuntu Forums and at Superuser which looks promising.
The steps which the script performs can be done manually and are basically this:
mkdir
dpkg-deb -x dkms...deb
dpkg-deb --control dkms...deb /DEBIAN
Edit the /DEBIAN/control file Depends line
dpkg -b dkms-modified-...deb
I am trying my hands new on Linux.
The following command is very useful:
sudo apt-get install <application>;
As it adds the application into the linux programs list and automatically upgrades it while running the update manager.
But I would like to get more knowledge on installing the programs from the .tar.gz archives as well.
So I do:
Extract the archive
./configure;
make;
make install;
I have two questions in this process:
1) I read in the forum that "make install" is not good if we are updating the binaries.
So should I just do "make" and the "install" ?
2) Second question is that is there a way to add the program installed in such manner to the Linux Software Update list so that I do not have to use the terminal for every new version that is released
Installing programs from tarballs:
You really do not want to install packages from .tar.gz when they are in the repositories. It is much harder to update or remove it manually than you could do with apt-get.
If you really have to compile the program yourself use checkinstall instead of make install. This creates a package you can install it via the package management and later remove using apt-get. This is much cleaner.
Also you may want to type
./configure && make && sudo checkinstall
instead of the commands you wrote. This way the program is only compiled if the configuration succeeded. The package is only built if the compilation succeeded. With ; instead of && all processes would be attempted no matter if its prerequisites are matched.
Graphical package managers
You can install your packages from GUI programs. Kubuntu uses for example uses muon for this, but the programs vary between distributions.
make install is "not good" if you want to be able to easily remove the files associated with a package as there is no log of the work it does and often no easy way to reverse the process. That has little to nothing to do with updating the software though (though updates can certainly run into related issues).
No, you can't add the manually compiled and installed software to your distributions list of packaged software (other than through something like checkinstall or creating a package yourself) since that's exactly what you were avoiding in the first place.
That all being said if the package exists for your distribution and you want to build it from source yourself you can often just build a more-or-less official version of the package from the distributions source package.
I need to manually compile and install FFMPEG as one of my dependencies using Puppet manifests. I want to do this myself to customize the configuration of FFMPEG to the needs of my project.
I'm not sure as to how to structure the entire process with classes. The logic should go something like this:
If /usr/local/bin/ffmpeg doesn't exist, compile:
Install build dependencies from apt-get.
Create a directory for the library sources /tmp/ffmpeg
Download and compile the Yasm assembler
Download.
Extract.
Configure
Make
Make Install
Download and compile x264
Clone the source.
Configure.
Make
Make Install
Download and compile fdk-aac:
...
....
I can easily branch all of these out into their own modules and declare them as dependencies of FFMPEG, that's not the problem.
My main problem is understanding how to do the whole download/extract/compile process for each module only if it's not already present on the system.
How do I structure my classes to only act if the software is not already installed?
Regardless of how you go about it, you need a way to check whether your custom installation has been installed.
Common methods include
checking a file and running a command only if it is not present: http://docs.puppetlabs.com/references/latest/type.html#exec-attribute-creates
running a command only if another command returns 0: http://docs.puppetlabs.com/references/latest/type.html#exec-attribute-onlyif (alternatively, the unless attribute)
I have a libfoo-devel rpm that I can create, using the trick to override _topdir. Now I want to build a package "bar" which has a BuildRequires 'libfoo-devel". I can't seem to find the Right Way to get access to the contents of libfoo-devel without having to install it on the build host. How should I be doing it?
EDIT:
My build and target distros are both SuSE.
I prefer solutions that don't require mock, since I believe SuSE does not include it in its stock repo.
Subsequent EDIT:
I believe that the answer I seek is in the build package. Perhaps it's SuSE's answer to mock? Or it's the distributed version of the oBS service?
DESCRIPTION
build is a tool to build SuSE Linux
RPMs in a safe and clean way. build
will install a minimal SuSE Linux as
build system into some directory and
will chroot to this system to compile
the package. This way you don't risk
to corrupt your working system (due to
a broken spec file for example), even
if the package does not use BuildRoot.
build searches the spec file for a
BuildRequires: line; if such a line is
found, all the specified rpms are
installed. Otherwise a selection of
default packages are used. Note that
build doesn't automatically resolve
missing dependencies, so the specified
rpms have to be sufficient for the
build.
Note that if you really don't need libfoo-devel installed to build package bar the most sensible alternative would be to remove libfoo-devel from the BuildRequires directive (and maybe put the requirement where it belongs).
However, if you cannot do that for some reason, create a "development" rpm database. Basically it involves using rpm --initdb --root /path/to/fake/root. Then populate it with all of the "target packages" of your standard distro installation.
That's a lot of rpm --install --root /path/to/fake/root --justdb package-name.rpm commands, but maybe you can figure out a way to copy over your /var/lib/rpm/* database files and use those as a starting point. Once you have the alternative rpm database, you can fake the installation of the libfoo-devel package with a --justdb option. Then you'll be home free on the actual rpm build.
If neither mock nor the openSUSE Build Service are a viable choice then you will have to buckle down and install the package, either directly or in a chroot; the package provides files that the SRPM packager has decided are required to build, and hence is in the BuildRequires tag.