Cheerio,
I am trying to use Assimulo 2.9. on a Mac OS X. For that I downloaded and installed sundials via cmake by creating a builddir to the Download file and ../Downloads/sundials-2.7.0 running
$cmake ../Downloads/sundials-2.7.0
$make
$make install
This should install everything in /usr/local.
It gives me no error warning when doing this. But when I am trying to use assimulo in python, following error message occurs:
from .sundials import IDA, CVode
ImportError: No module named sundials
Any suggestions?
Thank you very much.
The trick was to install everything through homebrew and get the missing sundials.so file. It seems that the current assimulo-2.9 distribution on pypi does not provide this shared object library and therefore triggers this error message.
I got the same error, in Anaconda(Ubuntu 18.04). I installed pyfmi first, and then installed the dependencies (assimulo, sundials) according to the error message. After everything was installed, the pyfmi was not working by running an fmu example.
But i uninstalled all the related software. Then i reinstalled everything with certain order. I found the order of installation matters, which are: sundials --> assimulo --> pyfmi.
Everything is good now.
Related
I have the following issue: I have installed anaconda 3 and installed a package called "pygrib" into my anaconda environment. Now when importing pygrib in a file in my environment, it will show me this error:
import pygrib
ImportError: libhdf5.so.10: cannot open shared object file: No such file or directory
As I am a noobie, I dont really know what to do with this information. I installed the h5py package and some other related ones, but it didnt resolve the issue. What to do?
This is a linking error with the HDF5 library. Are you building pygrib from source or using the conda-forge channel to install it via conda? When I use the conda-forge build of pygrib I get the same issue. The GRIB API from ECMWF (on conda-forge it is listed as ecmwf_grib) is what pygrib depends on and the HDF5 dependency comes from netCDF4 being used in the GRIB API library. Specifically, using the latest HDF5 (1.10.0 at this time) is what is causing a problem. Using HDF5 1.8.* instead allows pygrib to import properly.
To force conda to grab a specific version, just do:
conda install pygrib hdf5=1.8
This will get conda to solve the package specifications again with the older HDF5 library and likely clear up the issue. This assumes you are in the conda environment that you installed pygrib into. You could also create a new environment with conda create -n <env name> pygrib hdf5=1.8 if you wanted to.
In general, when you see these errors where a library is not found, it is often a matter of getting the right version of a library installed. With conda, this sort of thing happens when updating packages and a newer version of a library gets installed that a package you are using has not been properly linked with. As long as you can track down the package/library that is causing trouble, you can use the above procedure to start requiring certain versions of things get installed and conda should then update or downgrade things so that things work together again. Hopefully this makes sense and helps.
This part may or may not interest you, but what I cannot say for certain is where this problem originates. My guess is that it is something with ecmwf_grib and how it is built. That is where ldd shows the old HDF5 dependency showing up for my installation. If I can figure out the exact issue, I'll update this answer.
I have installed the following
C:\MinGW
C:\msys
C:\GTK
But python searching for the files in site packages and throwing the error as:
OSError: cannot load library libcairo.so.2: error 0x7e. Additionally, ctypes.util.find_library() did not manage to locate a library
This issue happening in installation of weasyprint packages.
Installing GTK+ didn't work for me.
I solved this problem using UniConverter2.0.
My environments is
Python 3.7
Windows 10 x64
Install uniconvertor-2.0rc4-win64_headless.msi,
Find the "dll" sub-directory under the UniConverter installation path.(In my case, C:\Program Files\UniConvertor-2.0rc4\dlls)
Add this "dll" path to the system path.
Close VSCode and reopen the project.
Try to run your code again.
Enjoy!
In my experience with this issue Windows 10 (64-bit) with Python 3.5.1, it can be either due to duplicate libraries in other directories seen by PATH that don't work or the libraries that you installed just aren't compatible with your OS/Python bit version.
I suggest installing an older version of GTK+ (I used 3.10.4) using the links provided in the WeasyPrint documentation instead and see if the error persists. I had the issue on a newer build of GTK+. The version of GTK+ installed with MSYS2 gave the same error.
Edit: I found the post where I found the previous version of GTK that I was using but it gave an annoying warning about the cairo version being unstable:
See this post.
Edit 2: To get rid of the cairo version stability warnings, I managed to get a newer version of Cairo using the GTK3-runtime-3.22.8 (Link to git downloads as per WeasyPrint docs)
Remember to uninstall all current GTK+ implementations first. You might get a warning saying that the version of cairo can cause issues but I haven't been able to locate a newer version of cairo that works in windows, let me know if you find one.
I need to run a program which use VTK5 on my Archlinux PC, but I found it really hard to install VTK5, there is only VTK6(not compatible with VTK5) in official repo, and when I try to install it from AUR, it returns "Makepg was unable to build vtk5", then I try to install through source code, the result is that I was unable to install the VTK Python module...
Is there anybody who has any experience or idea about it?
I have not installed on Archlinux specifically, but on different linux machines. If you compile from source and are interested in python, remember to select the option python wrapping when running cmake. Btw, once built, you will have to update both the pythonpath and the ldlibrarypath.
You can also have a try at enthought canopy, which distributes a complete installation with numpy, scipy, vtk http://docs.enthought.com/canopy/quick-start/install_linux.html
As suggested by Google, I'm trying to get http://jpegclub.org/jpegtran/ working on my Ubuntu server, but I'm getting the error:
"jpegtran: error while loading shared libraries: libjpeg.so.8: cannot open shared object file: No such file or directory"
A Google search told me to install (via apt-get) libjpeg-turbo8, however apt-get can't find the package. My own Ubuntu computer (running 12.0.10) can find the package just fine.
I tried installing http://sourceforge.net/projects/libjpeg-turbo/ with no luck.
Am I doing something wrong or have I missed something? How do I get jpegtran working?
This question may be old, but i was trying to run the glassfish updatetool and it failed because of the lack of the libjpeg library.
Steps i did take:
1. install libjpeg62:i386 (for 64 bit ubuntu amd6)
I hope it helps someone
I'm getting error while trying to install sqlite3-ruby gem:
gem install sqlite3-ruby-1.3.1.gem
Building native extensions. This could take a while...
ERROR: Error installing sqlite3-ruby-1.3.1.gem:
ERROR: Failed to build gem native extension.
/usr/bin/ruby.exe extconf.rb
Gem files will remain installed in /usr/lib/ruby/gems/1.9.1/gems/sqlite3-ruby-1.3.1 for inspection.
Results logged to /usr/lib/ruby/gems/1.9.1/gems/sqlite3-ruby-1.3.1/ext/sqlite3/gem_make.out
Same using:
gem install sqlite3-ruby-1.3.1
And that worked:
gem install sqlite3-ruby-1.3.1-x86-mswin32-60.gem
However I discovered I had had installed sqlite-ruby-1.2.5
Well my question is how 'gem' is installing these things? Why it can't choose sqlite3-ruby-1.3.1-x86-mswin32-60.gem version automatically. Does 'gem' is aware of running on linux or windows? What is native extension for it and why it is failing to install predownloaded sqlite3-ruby-1.3.1.gem
Thanks in advance
Lots of people seem to be having this issue. I'm surprised this doesn't work out of the box, as I would have guessed cygwin+ruby+sqlite is a supercommon configuration. Anyway. Many people concentrate on sqlite3.h, which is what appears are missing in the error output. However, my problem was that gcc wasn't installed correctly. Apparently gcc can fail to install correctly under cygwin. I fixed that and it was fine. Also, make sure you install libsql3-devel in cygwin.
I've been down this road before. I failed installing Ruby in Windows to work with Cygwin and I failed on Ubuntu.
What you do to save yourself the time and trouble is get a VM running with a Linux image (Fedora seemed to work well) and work with Ruby in that.