Does anybody have any experience with defining the python version of boost-python when installing from vcpkg?
I'm trying to use OpenVDB's python interface, and while I can get it working with the default python39 boost library, I'm not able to figure out how to define which boost-python version to install with vcpkg, and/or don't know how to define the correct parameters for the cmake command line to specify a python version at that point.
The default library that boost uses is 3.9, but as I'm typically in Anaconda, and 3.9 is not a standard download, I wanted to hold the boost library to be 3.8 instead.
I've commented in the github issues for openvdb, https://github.com/AcademySoftwareFoundation/openvdb/issues/946
but as this is not an issue with that project, and more of a dependencies thing, I thought I'd ask here in case you seen this on your travels :)
Thanks in advance for your time.
Neil
Related
I started getting the following warning repeatedly when running my PyTorch Lightning deep learning scripts, at execution start and then all through the training:
"OMP: Info #276: omp_set_nested routine deprecated, please use omp_set_max_active_levels instead."
I get them when executing the main.py script; my scripts are publicly available here.
Symptoms:
I don't think it has anything to do with PyTorch Lightning, maybe even PyTorch.
It appeared overnight, so I don't know what could cause it.
It runs fine without those warnings on my PC.
I get the warnings when I run from my M1 Mac.
I use VSCode for both, each up to date.
I use separate miniconda environments.
Thanks for taking the time to reply!
I managed to sort myself out in the end.
I spotted the numba package in my miniconda env, which is a Python compiler and that seemed to be the root of the problem.
It was version 0.55.2 but the last version to date is 0.56.0. Trying to upgrade it via conda or pip didn't work for some reason (the 0.55.2 version couldn't be replaced).
I recreated my env step by step, and noticed this package comes with torch-audiomentations, a package for audio data augmentation for deep learning, under torch, that I use.
Re-installing it had numba version 0.56.0 installed properly, and the warnings disappeared.
That routine is deprecated, meaning that newer standards want you to use another routine. If you can not edit the code, just ignore. For now it's only an info message. You got that message when you switched to a newer OS / compiler version / OpenMP version.
I am trying to build some source code on ubuntu 16.04 where one of the classes relies hierarchy_simplify_point_set.h header file, which is part of CGAL's point set package. After following instruction on the installation page, I have installed libcgal-dev and libcgal-qt5-dev via apt-get. The package manager has installed libcgal-dev 4.7 which should include the point set library. However, the particular header file seems to be missing (it seems to have some files from the point set library and not others - I am looking in /usr/include/CGAL). Does anyone know what I am doing wrong?
ps: For good measure, I have already tried uninstalling and reinstalling both the packages, but no luck.
This header has been introduced in CGAL 4.8 while it seems you are using CGAL 4.7.
You can get the latest version of CGAL here. Since the latest versions can be used as a header-only library, simply extract the release archive somewhere and set CGAL_DIR to that location when calling cmake to configure your example and it should work directly.
I need to install SUMO 0.30.0 to be used with the VEINS_INET subproject in veins 4.6. I have tried following the instructions here and suggestions from forums but haven't had any luck being able to install sumo. I run ./configure (trying various tool/library options) then run sudo make but all I get is target marouter failed or nothing to be done for 'install-exec-am' 'install-data-am'.
Does anyone know how to install sumo-0.30.0 from source and/or make the veins_inet subproject work with the latest version of sumo-0.32.0?
Don't run sudo make.
Don't run sudo make.
Your problem is probably related to a dependency/packaging change in 16.04, which is explicitly pointed out in the veins tutorial:
Note that Ubuntu 16.04 no longer includes libproj0; this can be worked around by temporarily adding the packet repository of, e.g., Ubuntu Vivid when installing this package.
Short answer: Unfortunately this means that long-term, you're going to either have to package SUMO yourself, use the versions someone else compiled (see this launchpad for example) or rely on an old version.
Long answer:
In general, I would recommend building SUMO from source by building its' dependencies from source, since I've encountered this problem on various distributions. In particular, the fox, proj and gdal libraries tend to be packaged in different versions, and along with changes in the SUMO source code. I currently use this script (with the package versions downloaded) to compile SUMO -- but this is for 0.30.0, and it breaks if any of the referenced source packages are moved (which happens quite often). My general recommendation would be to either use a completely isolated version of SUMO (i.e., compiling by hand as much as possible) or relying on a pre-packaged version (see above), as long as that version is recent enough to work with VEINS.
I want to install Go on CentOS 5.x, but Go website here http://golang.org/doc/install mentions that it is not supported.
Is there still some way to install Go Language on CentOS since CentOS is just a different flavour of Linux?
When I installed the same and ran the sample program hello.go mentioned at above website
I got the error
hello.go:3:8: import "fmt": cannot find package
package runtime: import "runtime": cannot find package
% export GOROOT=~/
% go run test.go
test.go:3:8: import "fmt": cannot find package
package runtime: import "runtime": cannot find package
Not finding the "runtime" package tells you that the $GOROOT enviroment variable isn't set to golang root directory.
You need to set $GOROOT. Also you should set the $GOPATH variable if you use external packages (go help gopath for more information).
A typical setup (not specific to CentOS) would be:
export GOROOT="/usr/local/go"
export PATH="$GOROOT/bin:$PATH"
export GOPATH=/Users/rodowi/gocode
At least for some programs it works fine. I have a production program that I compile on RHEL 6.x and deploy on 5.x and 6.x and it is working without any problems.
Edit: I used to use it under 1.0.3, but a few months ago I upgraded to "tip go" (the soon to be 1.1 version). Under 1.x it'd crash on 5.9 when accepting a tcp connection but that was fixed a few days after I reported it on the mailing list.
http://dave.cheney.net/2013/06/18/how-to-install-go-1-1-on-centos-5
This page explains rather well what kernel primitives are missing from the CentOS-5 kernel, their impact, and possible fixes.
I'm affraid you're out of luck because of the bit too much aged kernel version of CentOS 5.x. If the go runtime uses features simply not present in that kernel, then I see no easy way how it could work.
you could download the rpm package and begin installing locally, check below and download according to your OS:
http://pkgs.org/download/golang
or you could alternatively compile and build from source:
http://dave.cheney.net/2013/06/18/how-to-install-go-1-1-on-centos-5
Today I noticed this fairly old (and highly voted) question and it made me wonder, if pip is generally preferred over easy_install in the Python community, why is the official ipython.org documentation instructing newcomers like me to use easy_install as shown here?
Perhaps there is an implicit assumption that readers are using Python 2? Although the highly voted question and several answers all seem to indicate that pip is widely preferred over easy_install for both py2 and py3, so that seems like it's not the answer...
The command:
easy_install ipython[zmq,qtconsole,notebook,test]
will install IPython and some dependencies, including pyzmq, which has compiled parts.
easy_install handles binary packages, so it can install precompiled versions of things like pyzmq. pip, by contrast, only works with source packages. So for a package with compiled parts, it downloads the source code and tries to compile it. There are two problems with that:
The user needs to have a C compiler installed, plus whatever development headers the code being compiled relies on. The user often doesn't.
It's slow, especially for larger packages.
So the scientific Python world, which uses a lot of compiled packages, doesn't use pip as much as web developers. Actually, we don't much like easy_install either - we have a variety of more powerful installation methods.