I have written some software for a computer vision project, and want to make sure it is using the latest version of the libfreenect libraries and headers. Unfortunately, I can't figure out which are more up to date. There are several packages included with ROS, but there is also the libfreenect-dev package, which is what I used initially and referenced here. There have also been other random versions that can be found under the keyword "freenect".
My team is using the ROS package for other things, so I will probably use that except that the ROS package is a pain to work with and it doesn't, by default, offer support for the Kinect Accelerometer. I want to know where I can find the latest versions for Ubuntu libfreenect so I can make a better decision on what to use.
Related
I am programming the Raspberry Pi Pico-W and I would like to link against the C++ STL, in order to use some of the Standard Library functionalities and containers.
I have found the package on Ubuntu, which I used in a professional development environment and I therefore also wanted to install it on Fedora 36, but found it missing in the official and unofficial repositories.
Following packages are available to me currently, so it is really just the libstdc++ that is missing, since the C Library (newlib) is there.
arm-none-eabi-binutils-cs.x86_64
arm-none-eabi-gcc-cs.x86_64
arm-none-eabi-gcc-cs-c++.x86_64
arm-none-eabi-newlib.noarch
libstdc++.i686
libstdc++.x86_64
libstdc++-devel.x86_64
One option I got recommended was to get the headers manually from arm itself, which also includes the rest of the toolchain.
Is there some package I am missing in the Fedora repositories, or is it just really not available as one package?
Fedora does not seem to provide such packages and I have also not been able to find copr repos for that.
Therefore the only solution left, was to install directly from arm.
This link gives a short guide for those that need it.
Additionally, since I am using NeoVim with its built-in lsp, I need to add a flag to the clangd configuration, namely --query-driver=/*/*/bin/*gcc, which globs for the compiler found in the compile commands. But this only as a side note.
After that everything seems to work as one would expect.
I'm working on a project in the D language and I want to use a module from the standard library called std.sumtype. I'm on debian oldstable, and I've tried both GDC and LDC. DMD is unavailable, because I'm using a machine with an armhf architecture. Neither of these compilers can find std.sumtype, despite it being in the standard library. I also tried downloading 3 different versions of sumtype.d from the phobos repositories of all three D compilers. Each of these would not compile. How can I use this? Am I on the wrong version?
std.sumtype is a pretty new package that was added in 2.097.0: https://dlang.org/changelog/2.097.0.html#std-sumtype so the debian oldstable packages probably don't have it yet as you would need at least:
DMD 2.097.0
LDC 1.27.0 (beta.1 or above)
upcoming GDC in May 2022 (see announcement)
If you want to use the latest compiler you could always download the latest LDC archive and extract it somewhere and run it from there or use the install.sh script from the download page for portable and multiple simultaneous installs.
std.sumtype is an adoption of the dub package sumtype so if you are using dub, you can depend on that as well and not need to get another compiler outside the package manager.
I'm using eclipse neon in windows. I want to use surf in C++ and I'm unable to find a solution. I currently have opencv 3.3.0 for which I made the eclipse build using cmake. Do I really need non-free module or is there another way? And how can I add non-free module?
See here but in summary SURF has been moved to the contrib module in OpenCV3.0
SIFT and SURF are examples of algorithms that OpenCV calls “non-free” modules. These algorithms are patented by their respective creators, and while they are free to use in academic and research settings, you should technically be obtaining a license/permission from the creators if you are using them in a commercial (i.e. for-profit) application.
With OpenCV 3 came a big push to move many of these “non-free” modules out of the default OpenCV install and into the opencv_contrib package. The opencv_contrib packages contains implementations of algorithms that are either patented or in experimental development.
here is a tutorial on how to install the contrib library using cmake which does not happen by default.
According to SURF author Herbert Bay , he has published the original source code to https://github.com/herbertbay/SURF . It should be more robust than the OpenCV version. So you don't need non free module anymore to work with SURF
I'm new to Linux, but I'm trying to distribute an application in .deb and .rpm format. I'm having trouble with the below three libicu libraries:
libicui18n.so.52.1 => not found
libicuuc.so.52.1 => not found
libicudata.so.52.1 => not found
The problem is that the version required for the application does not always match the version installed on the system, for example Fedora 26 comes with libicu 57.1 while my application is looking for 52.1. Adding libicu to the package dependency list doest help, because libicu is already installed, so installing libicu just gives:
Package libicu-57.1-6.fc26.x86_64 is already installed, skipping.
Dependencies resolved.
Nothing to do.
Complete!
I couldn't find a package for libicu52.1, but trying to install an older package doesn't seem to work anyway. I tried libicu-54.1-4.fc22.x86_64 but it says no package available, presumably because it's only available on Fedora 22.
I was thinking of including the libraries in the application package and having them install to /usr/lib64, but being a Linux newbie I'm unsure if this is an acceptable thing to do.
What's the best way to solve this?
Edit: I saw this post in the related section which says:
Newer versions of libraries should not break existing apps unless
you're using deprecated features.
I'm testing on Fedora 26 which comes with libicu 57.1. My application only requires libicu 52.1, so if the above is true I assume it should be working. Is there something I need to do to make it work?
Having your package install "extra" versions of libicu to /usr/lib64 would be very surprising to most users. Don't do that.
The standard practice here is to build different .deb and .rpm files per target platform. The same as you need to build separately for 32-bit vs 64, you need to build separately for, say, CentOS 6 vs 7. You can do this by running a set of virtual machines to do the release builds--one for each target platform you want to support.
If you truly need to make a single .deb or .rpm that works on many platforms, one way is to eliminate some of your dependencies. In this case, all those libraries are part of the same project (ICU), so if you don't really need to depend on that project, don't.
I was able to install and build openCV following the instructions here (http://charliegerard.github.io/blog/Installing-OpenCV/). But after successfully creating the dynamic libraries I noticed in the lib directory there are 3 instances of each library named in the following format:
libopencv_LibName.3.1.0.dylib
libopencv_LibName.3.1.dylib
libopencv_LibName.dylib
Screenshot of the libraries
My next step is to single out only the header files and libraries I need for my project, and I'm not sure if I really need all 3 instances of every library in use. Why does make create all these extras? And which ones do I need?
Additional Info:
OS: OSX El Capitan
IDE: Xcode 7.3.1
When you build the opencv library it creates the actual *.dylib binary (libopencv_LibName.3.1.0.dylib) that contains the release, the major, and minor version. (Release = 3, Major = 1, Minor = 0). This allows you to have a dynamic style of linking to a specific version of the library. (For example, opencv often is not completely compatible between release versions. (From 2.x.x to 3.x.x), however it often is compatible between major/minor versions.(3.0.x to 3.1.x) )
By linking to the 3.1.0 version, you are locking in on requiring that specific version of the libary. (If you update opencv, it will still be using openCV 3.1.0).
However if you link to the 3.1 version, it is only caring about the Release and Major version, but will allow minor version updates. (Currently the 3.1 is a symlink to 3.1.0, but if you installed 3.1.1, it would now reference the 3.1.1 library.) I generally find it best to link to this one as it will allow you to update for bug fixes, but will not break any functionality.
Finally there is the version-less symlink, this one will always reference the latest version of opencv you have installed. Currently it references 3.1.0, but if you installed 3.1.1 it will now reference 3.1.1. This would not be bad, but if you were to install 4.0.0, it would now be referencing this binary and likely break some of the API.