I am trying to compile freshly installed PCL library in WSL. I followed the steps given in the thread: https://stackoverflow.com/questions/58040066/how-to-compile-point-cloud-library-pcl-with-examples-ubuntu. I installed all the required dependencies mentioned in the thread but I am running into compilation error.
CMake Deprecation Warning at CMakeLists.txt:15 (cmake_policy):
The OLD behavior for policy CMP0048 will be removed from a futur
version of CMake.l/lib/cmake/vtk 9.2/FindFreetype.cmake:179(vtk_detect_library_type)
/usr/local/lib/cmake/vtk-9.2/patches/3.19/FindX11.cmake:235(find_package)
The cmake-policies(7) manual explains that the OLD behaviors of al
(find_package) policies are deprecated and that a policy should be set to OLD only under specific short-term circumstances.
Projects should be ported to the NEW behavior and not rely on setting a policy to OLD.
The cmake-policies(7) manual explains that the OLD behaviors of all
policies are deprecated and that a policy should be set to OLD only
under specific short-term circumstances.
--Could NOT find LIBUSB_1 (missing: LIBUSB_1_LIBRARY LIBUSB_1_INCLUDE_DIR)
-- Checking for module 'metslib'
-- No package 'metslib' found
-- Configuring incomplete, errors occurred!
-- QHULL found (include: /usr/include, lib:
optimized;/usr/lib/x86_64-linux gnu/libqhull.so;debug;/usr/lib/x86_64-linux-gnu/libqhull.so)
CMake Error at /usr/local/lib/cmake/vtk 9.2/vtkDetectLibraryType.cmake:23 (message):
The `PATH` argument is required.
Projects should be ported to the NEW behavior and not rely on
setting a policy to OLD.
I did not quite understand the warning written in the first line. Does it have to do anything with the CMake version? I am new to cmake and cannot figure this out. Some help will be appreciated :)
You are trying to compile on a WSL which is just a subsystem i.e. it's without an X-server. Simple as that. Look at this line:
/usr/local/lib/cmake/vtk-9.2/patches/3.19/FindX11.cmake:235(find_package)
Long story short, you can't might be able to compile it on WSL, because but VTK needs an X-server for it's visualisation and you need to start by getting the X-server up and running. I'm really not sure how this would run on a WSL even if you got an X-server to work with WSL, but I might be wrong here.
EDIT: Apparently it is possible to get an X-server to work on WSL by forwarding it, but I still believe (especially since you are new) that it's more work then just getting a dual-boot working.
EDIT2: Tsyvarev was kind enough to provide a great link on how to get X-server configured on WSL.
Related
I am using VS Code 1.68.1 on Windows 10 and have installed the Haskell language support plugin. I tried to install ghcup but the installation script just fails with no error message and the IRC channel #ghcup wasn't able to help so I've given up on ghcup and decided to handle this manually. I just installed HLS 1.7.0 and pointed VS Code at it. The problem is I get an error message from VS Code:
ghcide compiled against GHC 9.2.2 but currently using 8.6.5
This is unsupported, ghcide must be compiled with the same GHC version as the project.
Upon further investigation, this seems to be complaining that the ghcide library that's a part of HLS was built using ghc 9.2.2 but my current codebase was built (by Stack) using ghc 8.6.5. At least that's my reading of it, since the HLS page itself says that 1.7.0 is compatible with 8.6.5! So my first question is how on earth am I supposed to know what version of ghc was used to build HLS, and honestly why should I care?? And my second question is, how do I find the version of HLS that's compatible with my current ghc?
(Another option is to migrate Stack from 8.6.5 to 9.2.2 but I'm not sure exactly how to do this. It appears to be just a case of changing the resolver entry in stack.yaml which is currently resolver: lts-14.21. But what do I change it to? It looks like the most recent version of LTS is 19.14 https://www.stackage.org/lts-19.14. But I'm a bit nervous about making that change since the page says ghc 9.0.2 not 9.2.2. The entire Haskell ecosystem just seems really finicky and I'm new enough to Stack that don't want to end up with a messed up Stack config and possibly in Haskell package mismatch hell.
Can anyone offer any good solutions?
I'm researching how much of the solution I have for Windows can be simply transplanted to Linux. Most of my actual program can operate, but our favourite logging module on Windows is NLog.
I'm having a problem on openSuse. When NLog starts (i.e. valid configuration is found), the program fails with several errors of the form:
Can't find custom attr constructor image: /share/MonoSIMON/MonoTestConsumer/NLog.dll mtoken: 0x0a000358
The error appears 9 times with NLog 3.2.0.0.
Initially I was running with a newer NLog V4.3.1.0, and the result is the same although there are around 15 copies of the error instead.
I'm not compiling Mono or anything, it's all as standard packages. I'm targeting Framework 4.5, it's a Console App, and I'm really not doing anything special.
Is it possible to run with NLog on openSuse.
Thanks for any help.
Mark
I eventually worked this out. Julian pointed me back in the direction of the NLog issues board, but that package name doesn't work on openSuse 42.1.
A search on www.rpmfind.net shows that the system.service model assembly is actually in the openSuse 'mono-wcf' package.
zypper install mono-wcf
Fixes the NLog problem.
Cheers.
I'm getting the following error while building FireBreath Solution file .
The C Compiler Identification is unknown and
The CXX Compiler Identification is unknown
Can any one help me figuring out where am I doing wrong.
Note: 1) I have VS professional installed with c++ compilers and libraries
This may help
start visual-studio-2012 command prompt (e.g. Win64)
run cmake command with appropriate generator (e.g. -G "Visual Studio 12 Win64")
My research indicates that this is most likely a broken visual studio installation. You can try uninstalling / reinstalling, but if that doesn't work you might try making a new question that isn't tied to firebreath or plugins (which leads people to think they need to know something about firebreath or plugins to help you) and just asks about the error you're getting with cmake, since hte issue is actually that cmake isn't finding Visual Studio.
I have had this happen to me once before with VS2010 and to be honest I just ended up reinstalling the system. There is a thread about a similar issue where someone fixed it by copying an installation from another computer.
Other than that, I really have no idea.
Has anyone been able to build NSS statically linked? I actually only need to build certutil and pk12util statically linked. I've seen that Chromium is building NSS statically, and they even have a patch file, but the whole build process is quite involved and I'm just trying to do a small subset. Any help would be greatly appreciated.
As it is right now, NSS cannot be built statically. There is some work in progress in bug 534471 and bug 533014 (NSS and NSPR respectively) but these patches are quite old and likely don't apply any more. It seems that nobody at Mozilla is currently working on this.
As to Chromium, they are using a heavily patched NSS version. Also, they are using GYP to build NSS, not the Makefiles normally supplied with NSS. You could probably build their NSS version but I'm not sure whether it is really useful outside Chrome. The relevant directories are deps/third_party/nss/ and src/net/third_party/nss/, former being NSS without libssl and the latter being libssl only.
I have about a few problems with a new install of the Qt SDK. I probably only need advice, but specific answers are also welcome. Before I begin a mini-story, I am running RHEL5 on academic license under VirtualBox on OSX 10.6. Using Qt version 4.5.3. This is my situation...
1.) I couldn't compile because g++ wasn't found. I fixed this by creating a link: g++ -> g++34. This allowed me to compile but it generated more errors at link-time. I had installed the framework in my home directory unintentionally so I uninstalled/reinstalled the entire SDK to /usr/local/qt.
2.) At this point I could compile but the linker complained about a missing freetype package. I had that already installed but wasn't sure why it couldn't be found. So I installed a few packages that I thought might be missing like libqt4-devel and libqt4-devel-debug. I also installed a few other general programming packages for later use.
3.) Somehwere in this process I can no longer run qmake. I ran it before and I have it installed at /usr/local/qt/qt/bin/qmake. I could create a link to it (though I shouldn't have to OR I could ensure that the location was in the PATH var). However, at this point Qt Creator says there's no Qt installation found. I re-pointed it to the installation location (using Tools/Options) but it still won't run qmake or anything else for that matter...
I only need this linux install to compile and test my Qt projects which I am developing in OSX. So my question is, should I just wipe this RHEL install and start over? And if so, should I use something else like Ubuntu? I am having plenty of hassles that I don't want to deal with as is. Note, this project will require good OpenGL support.
Is there a particular reason that you don't simply use the Qt package that's part of RHEL?
If for some reason you need to build your own, you can get all of the build dependancies with:
$ yum install yum-utils
$ yum-builddep <whatever the qt package's name is>
#scotchi is right, and you should try to use the Qt package that comes with your system unless you need a very different version. I don't know what version of Qt comes with RHEL but if its not up-to-date enough for you (and it might not be, see below) then you could consider changing OS versions. I would only do this after trying his suggestion though, because you may be able to get things working without the hassle of a full OS install.
Now, as to why you might want to switch: RHEL is, as its name ("Enterprise Linux") indicates aimed at companies who want to run servers, or large deployments of desktops. It emphasizes stability and reliability over being cutting edge. Fairly often the version of the compiler and development libraries lag a little behind the curve. This is what their clients want: a stable platform they can develop against and run programs on for a period of time, not constantly needing to keep up with the latest changes, and thoroughly tested. But for people doing development at home it may not be necessary to stay that conservative. I don't know if this is for work, school or personal programming, but it sounds to me like you should move to one of the more desktop-oriented distros. Ubuntu is great, as is Fedora. If you prefer a RHEL-like environment, then choose Fedora.