I got the error libpl (shared) not found.(see below for details) when using pyswip (mac). I know there is a question about it posted several years ago, but it is not solved. I installed swiprolog(>7.0.0) with homebrew and run 2to3 for pyswip. Help me.
PS: I am learning logic programming, I need it.
libpl (shared) not found. Possible reasons: 1) SWI-Prolog not
installed as a shared library. Install SWI-Prolog (5.6.34 works just
fine) An exception has occurred, use %tb to see the full traceback.
The error is thrown here.
# UNIX-like
try:
_lib = CDLL("libpl.dylib")
except IndexError:
# let's try the cwd
_lib = CDLL("./libpl.so")
I finally found a solution: pyswip does not support SWI-Prolog 8.x.x and the only SWI-Prolog version that has worked for me is Homebrew's swi-prolog 7.6.4 (latest 7.x.x stable release). Because Homebrew does not keep track of different versions of swi-prolog, I had to really dig to find the old 7.6.4 "formula". Now it works with the current version of pyswip (0.2.8).
TL; DR: Remove your current SWI-Prolog install (and remove any associated PATH editing), do brew install https://raw.githubusercontent.com/Homebrew/homebrew-core/09a94009142a6265b0b8e322463100610aeda964/Formula/swi-prolog.rb and call it a day.
EDIT:
Caveat: This approach will not let you use some Prolog packages such as library(process) and library(http/json). To correct this, you can install the macOS app and manually install and relink the libncurses.6.dylib in order for PySwip to be able to find it, like this:
brew install ncurses # Specifically install this library
sudo find / -name "libncurses.6.dylib" # You'll see an entry in /usr/local/Cellar/ncurses/6.1/lib/libncurses.6.dylib or something like that in /.../Cellar/ncurses/ (Homebrew folder)
# Now go relink the libswipl.dylib to depend on the newly installed `ncurses` library
cd /Applications/SWI-Prolog.app/Contents/swipl/lib/x86_64-darwin15.6.0 # The "darwin" version may vary depending on your OS/SWI-Prolog version
# You'll see that it is linked against a fake /opt/local/lib/libncurses.6.dylib which doesn't in fact exist
otool -L libncurses.6.dylib
# Now check the top-level lib, libswipl.dylib, it should show a "#executable_path/../swipl/lib/x86_64-darwin15.6.0/libncurses.6.dylib" or something like that depending on your version.
otool -L libswipl.dylib
# Now replace the fake with the real by actually modifying the top-level lib, libswipl.dylib. Contrary to intuition, the way linking works in macOS is that you can only modify the depending library, so libswipl.dylib instead of libncurses.6.dylib.
install_name_tool -change #executable_path/../swipl/lib/x86_64-darwin15.6.0/libncurses.6.dylib /usr/local/Cellar/ncurses/6.1/lib/libncurses.6.dylib libswipl.dylib
# Now you'll see that libswipl.dylib has been successfully modified:
otool -L libswipl.dylib
Related
After installing the Nest Neural Simulator, I keep getting the following error when trying to run any of the example python files that came in the installation. I've tried re-installing Nest, Python, and using Anaconda, but no go.
Python error:
ImportError: No module named nest
Suggestions?
At https://nest-simulator.org/documentation you now find many different install instructions and how to solve the "ImportError: no module named nest" depends on the way you installed NEST.
System Python
The problem with the nest python module not being found is usually, that NEST is installed for a specific Python version and you can not load it from another. So while many OS still use Python 2.7 you may need to explicitly run
$ python3
>>> import nest
Additionally, if you have multiple Python 3.x versions installed, modules may still be installed for a different version and you have to explicitly start python with python3.6 or python3.8, etc.
Conda package
As #nosratullah-mohammadi already mentioned, if you have a Conda flavour installed, using the pre-built package is a very quick solution. The link in his post is unfortunately broken; this one should work, then go to "Installation" in the side bar.
$ conda create --name nest -c conda-forge python3 nest-simulator
$ conda activate nest
$ python # this should load the Python from the conda env
>>> import nest # this loads nest which is installed explicitly for that Python
From Source
For every install from source, be sure to have Python and other prerequisites installed before building NEST. Then you can create your temporary build directory (can be deleted afterwards) and configure with the flags you need.
cd somewhere
mkdir nest-build
cd nest-build
cmake -DCMAKE_INSTALL_PREFIX:PATH=/install/path -Dwith-python=3 .../sources/of/nest-simulator
Replace somewhere, /install/path and .../sources/of/nest-simulator with the paths correct for your setup. (A popular choice when compiling from source in conjunction with Conda environments, for example, is to use -CMAKE_INSTALL_PREFIX=$CONDA_PREFIX, which installs NEST directly into the active environment. Conda is however in no way necessary for NEST.)
Add more -D... flags as you prefer. Possible flags you see with cmake -LA .../sources/of/nest-simulator, as pointed out here. You are probably interested in many of the with-xyz at the end. Check the aforementioned documentation for deatils.
Check that the paths and libraries reported in the Configuration Summary make sense (you may need to scroll up a bit to see). It could for example look something like this:
--------------------------------------------------------------------------------
NEST Configuration Summary
--------------------------------------------------------------------------------
[...]
Python bindings : Yes (Python 3.6.8: /home/yourname/miniconda3/envs/nest/bin/python3)
Includes : /home/yourname/miniconda3/envs/nest/include/python3.6m
Libraries : /home/yourname/miniconda3/envs/nest/lib/libpython3.6m.so
Cython bindings : Yes (Cython 0.27.3: /home/yourname/miniconda3/envs/nest/bin/cython)
[...]
--------------------------------------------------------------------------------
[...]
PyNEST will be installed to:
/home/yourname/miniconda3/envs/nest/lib/python3.6/site-packages
--------------------------------------------------------------------------------
In this example CMake configured everything for Python3.6 from my conda environment.
If you are satisfied with your settings and all the found Python versions match, run the usual
$ make # optionally with -j$(nproc)
$ make install
$ make installcheck
In case that works out fine you are done and can delete the build directory to free the space. Congratulations!
Also if things get too mixed up and it doesn't seem to do what you expect, it is sometimes useful to delete the build directory and start off clean.
there is a new method of installation added to other methods, wich is installing nest with conda package and it's in its beta version. but it works and it's really simple.
you can find the installation from here!
simply after install mini conda package run your terminal and type this :
conda create --name ENVNAME -c conda-forge nest-simulator python
then type :
conda activate ENVNAME
and you're good to go!
NEST now provide the solution to that problem and similar ones, by providing a script which automatically sets the relevant system variables:
If your operating system does not find the nest executable or Python
does not find the nest module, your path variables may not be set
correctly. This may also be the case if Python cannot load the nest
module due to missing or incompatible libraries. In this case, please
run
source </path/to/nest_install_dir>/bin/nest_vars.sh
to set the necessary environment variables. You may want to include
this line in your .bashrc file, so that the environment variables are
set automatically.
https://nest-simulator.readthedocs.io/en/latest/installation/linux_install.html
Turns out I needed to move the directory where I installed nest (Users/name/opt/nest) into a nest folder in the following directory in anaconda. Specifically, I moved the contents of the folder (from the nest installation):
/Users/name/opt/nest/lib/python2.7/site-packages/nest
Into this one:
/anaconda/lib/python2.7/site-packages/nest
Disclaimer: I could very well run into problems for not having copied all the contents of the Nest installation, but this little hack is helping me run example files now.
I am trying to install jedi-vim. I am doing this at work - so I have to use gVim in Windows. I have already read several other posts in this forum. This has somehow made me smarter but still does not solve my problem.
I did the following things:
installed Pathogen
cloned jedi vim from https://github.com/davidhalter/jedi-vim.git and copied it to the bundle/ folder in the vim-dir.
Now, when I open a *.py-file vim always tells me
jedi-vim requires vim compiled with +python
but ':version' tells me that it's compiled with +python/dyn and +python3/dyn.
So what is the problem?
Additional infos:
vim version: 7.4
When I use ctrl+space to autocomplete a python key word, it tells me:
Error detected while processing function jedi#completions: line 1: E492: Not an editor command: Python jedi_vim.completions()
Error detected while processing function jedi#completions: line 1: E492: Not an editor command: Python jedi_vim.completions()
Press ENTER or type command to continue
I'm not sure if your are still experiencing the same issue, but after looking around I found this blog post that solved the problem for me. Essentially, it's just about re-installing vim (don't delete any config files) and then reinstalling from the source at the vim mercurial repo with the right flags. There might be a shorter/simpler version of doing this, but after trying back and forth many solutions, this one was the only one that worked:
Compiling Vim with Python and Ruby support on Ubuntu
These are the steps:
Check if Vim is compiled with Python:
$ vim --version | ack '(python)'
Remove Vim version installed:
$ sudo apt-get remove vim-common vim-runtime
Install dependencies needed to compile Vim:
$ sudo apt-get build-dep vim
Clone Vim repository, compile it and install the new version:
$ hg clone https://vim.googlecode.com/hg/ vim
$ cd vim
$ ./configure --enable-pythoninterp
$ make
$ sudo make install
+python/dyn means that Python support isn't statically compiled it, it's loaded dynamically when needed at runtime.
This is described in the python-dynamic help section:
On MS-Windows the Python library can be loaded dynamically. The |:version| output then includes |+python/dyn|.
This means that Vim will search for the Python DLL file only when needed.
When you don't use the Python interface you don't need it, thus you can use
Vim without this DLL file.
To use the Python interface the Python DLL must be in your search path. In a console window type "path" to see what directories are used.
The name of the DLL must match the Python version Vim was compiled with.
Currently the name is "python24.dll". That is for Python 2.4. To know for
sure edit "gvim.exe" and search for "python\d*.dll\c".
(Don't worry about the 2.4 there; I just happened to find docs from a few years ago. Read the help in your own copy of vim—or, better, do what the last paragraph says.)
So, either you don't have Python, you have the wrong version of Python, it's not on your %PATH%, vim is searching for it incorrectly, or it's failing to load.
At that time the problem was another one. I mixed up the architectures for vim and python - I used vim64Bit, but pyhton for 32bit.
I repaired that already some time ago but the other day I had to restart my computer and do some microsoft-Updates.
Unfortunately my vim (7.4) was totally broken. I had to re-set my home-dir. Then at least my vimrc was accessible again, but still my jedi in vim does not work.
Python is available in vim but still jedi does not seem to load correctly.
When I type "len(" in the beginning of a .py-file, at the place where arguments should be explained there are some strange characters, similar to this:
==jedi=0, == (_object_*) ==jedi==
When I type "self.", it says "unknown function: pythoncomplete#Complete"
I think it's only a configuration-issue, because it worked before the reboot.
Jedi is installed systemwide (with pip). If I try to install it "again", pip says that jedi is already installed.
I would appreciate your help very much ;-)
I installed vim from source according to this link and it was succesful. But there is no python- support. I have installed python-dev and I've looked for the directory the Python config-file is in to set the right flag:
--with-python-config-dir=/usr/lib/python2.7-config
--enable-pythoninterp
I've installed vim from source two times, because the first time I forgot sth.
How can I get python-support now?
The installation guide you showed also states
You may need to add --with-python-config-dir=/usr/lib/python2.7/config-x86_64-linux-gnu/ to the configure call.
Have you tried this?
FYI, this is the contents of the directory on my Debian jessie (aka testing) x86_64.
$ ls /usr/lib/python2.7/config-x86_64-linux-gnu
Makefile Setup Setup.config Setup.local config.c config.c.in
install-sh* libpython2.7-pic.a libpython2.7.a libpython2.7.so# makesetup* python.o
I want to use unoconv with LibreOffice 4.2, but it seems like I can not start the python of LibreOffice.
When I run
/Applications/LibreOffice.app/Contents/MacOS/LibreOfficePython.framework/Versions/3.3/Resources/Python.app/Contents/MacOS/LibreOfficePython -v
The error is:
dyld: Library not loaded: /usr/local/libodep/lib/libintl.8.dylib
Referenced from: /Applications/LibreOffice.app/Contents/MacOS/LibreOfficePython.framework/Versions/3.3/Resources/Python.app/Contents/MacOS/LibreOfficePython
Reason: image not found
Trace/BPT trap: 5
Not directly an answer to the original question, but I ended up on this page after searching for the same error message, while running gpg. Turns out gettext was mangled during upgrade of ios. The following sorted it:
brew install gettext
brew link gettext --force
I just ran into the same issue. The fix is ugly, but essentially follows Michael's approach. The lib is provided by MacPorts and installed there:
> find /opt/ -name 'libintl*'
/opt/local/include/libintl.h
/opt/local/lib/libintl.8.dylib
...
A simple softlink into /usr/ does the trick, but gee do I dislike polluting trees like this!
> sudo bash
> mkdir -p /usr/local/libodep/lib
> ln -s /opt/local/lib/libintl.8.dylib /usr/local/libodep/lib/libintl.8.dylib
With this, the Python 3.3 from LibreOffice runs. I sure hope that somebody at LibreOffice is going to fix this. Anybody know if a bug has been filed?
The library it's attempting to load isn't a standard dylib on MacOS. Whoever created LibreOffice should have either included the dylib in their app package somewhere or they should have included instructions on how to set things up properly for LibreOffice.
From what I can tell, it looks like you need to install MacPorts in order to pick up libintl.8.dylib.
And MacPorts is likely to install that library into "/opt/local/lib/" instead of "/usr/local/libodep/". Not sure if LibreOffice is smart enough to know what to do in that case but you can do a symbolic link from a file in one directory to a sym link in another directory in a pinch if you're desperate.
I came across the same issue as:
dyld: Library not loaded: /usr/local/lib/libintl.8.dylib
Referenced from:
/opt/local/bin/yasm
Reason: image not found
Trace/BPT trap: 5
I had to install MacPorts and gettext, which installs the libintl.* libraries in /opt/local/lib
MacPorts defines the dependency of yasm on gettext
You'll find the same topic here for followup:
https://github.com/dagwieers/unoconv/issues/125
Though the provided answers didn't work for me, installing macports didn't work for me,
libintl.8.dylib I didn't find on /opt/local/lib/
I found others have the problem not being compatible.
gettext also didn't work for me.
I have another thread asking help on "missing zlib". With the nice help the problem has been resolved (almost).
Now I am interested in building Python myself (on Ubuntu 10.10).
A few important questions have caught my attention:
After building Python (say 2.7.1), do I need to rebuild Python if I have missing modules?
Is there a way to find out what modules will be missing prior to building Python? Say sqlite3. I have sqlite3 installed for the system default (Python 2.6.6), and I can import that into Python 2.6.6 shell. Now I use pythonbrew to build 2.7.1, and in the shell I cannot import sqlite3 because _sqlite3 is not available. I am sure there are a few more important one missing which I need for future development (such as Django..).
I am willing to learn how to build without using pythonbrew.
Please share with me your experience in building another version of Python, and how would you address the problem of missing modules? Is there a practical solution to building Python?
I have never bothered building one myself, so please bear with me. I am beginning to realize the importance of learning and building one myself! Thank you very much!
EDIT
First I thank you all of your inputs. They meant a lot. I did the building.
Python build finished, but the necessary bits to build these modules were not found:
_bsddb _curses _curses_panel
_tkinter bsddb185 bz2
dbm gdbm readline
sunaudiodev _sqlite3
To find the necessary bits, look in setup.py in detect_modules() for the module's name.
I got sqlite3 and readline away by
sudo apt-get install libreadline6 libreadline6-dev
sudo apt-get install libsqlite3-dev
I tried to import them, but still "no named module xxxx".
At AskUbuntu I actually asked people how to get previous commands because I couldn't use that feature when I am in Python 2.7.1 shell. I believe it's due to readline.
Readline
I installed the Python-2.7.1 under this directory: /home/jwxie518/python27/
I looked into setup.py, I found the following lines:
# The sqlite interface
sqlite_setup_debug = False # verbose debug prints from this script?
# We hunt for #define SQLITE_VERSION "n.n.n"
# We need to find >= sqlite version 3.0.8
sqlite_incdir = sqlite_libdir = None
sqlite_inc_paths = [ '/usr/include',
'/usr/include/sqlite',
'/usr/include/sqlite3',
'/usr/local/include',
'/usr/local/include/sqlite',
'/usr/local/include/sqlite3',
]
All the paths listed above do not exist.
So I guess I have to install sqlite3 manually? I got another reference here (it's in Chinese, however)
# Download the latest and extract
# Go into the extracted directory
./configure --prefix=/home/jwxie518/python27/python
make && make install
# Then edit python-2.7 's setup.py before rebuild it
# Sample (add these two lines to the end....)
'~/share/software/python/sqlite-3.6.20/include',
'~/share/software/python/sqlite-3.6.20/include/sqlite3',
# Then rebuild python like how we did before
I went into my directory where I installed sqlite3. I found include/sqlite3.h only. So I went back and check /usr/include/. I can only find sqlite3.h too.
So what is going on here? Readline is also non-importable.
3RD EDIT
I started everything over, except I didn't reinstall sqlite3.
# Extract Python-2.7.1
# cd into Python-2.7.1
# ./configure
make >make.out 2>&1
less make.out
make.out is here: http://pastebin.com/raw.php?i=7k3BfxZQ
I still couldn't import sqlite3. So I went into setup.py and made changes:
# We hunt for #define SQLITE_VERSION "n.n.n"
# We need to find >= sqlite version 3.0.8
sqlite_incdir = sqlite_libdir = None
sqlite_inc_paths = [ '/usr/include',
'/usr/include/sqlite',
'/usr/include/sqlite3',
'/usr/local/include',
'/usr/local/include/sqlite',
'/usr/local/include/sqlite3',
'/home/jwxie518/python-mod/include/sqlite',
'/home/jwxie518/python-mod/include/sqlite3',
]
Then again, ran everything over (this time I also did make clean)
Output is here: http://pastebin.com/raw.php?i=8ZKgAcWn
According to the output, I don't think the custom path is included.... (for complete output please go to the link above and search for sqlite)
build/temp.linux-i686-2.7/home/jwxie518/Python-2.7.1/Modules/_sqlite/util.o
-L/usr/lib -L/usr/local/lib -Wl,-R/usr/lib -lsqlite3 -o build/lib.linux-i686-2.7/_sqlite3.so
I still cannot import sqlite3.
THanks!
Thank you very much, Michael Dillon, for helping me out. Your tutorial was neat and clear.
I solved the problem as soon as I realized whenever I tried Python-2.7.1, I was actually using the one installed by Pythonbrew.
The moral of the story is read all the errors. I neglected the errors generated by importing sqlite3. The one installed by Pythonbrew didn't have sqlite3 installed. The development package for sqlite3 was installed after Pythonbrew installed the Python-2.7.1
Thanks.
Here is how to build Python and fix any dependencies. I am assuming that you want this Python to be entirely separate from the Ubuntu release Python, so I am specifying the --prefix option to install it all in /home/python27 using the standard Python layout, i.e. site-packages instead of dist-packages.
1. Get the .tar.gz file into your own home directory.
2. tar zxvf Py*.tar.gz
3. cd Py*1
4. ./configure --prefix=/home/python27
5. make
6. make install
Step 5 is the important one. At the end, it will display a list of any modules that could not be built properly. Often you can fix this by installing an Ubuntu package, and rerunning make.
a. sudo apt-get install something-dev
b. make
It is pretty common to have a problem because you are missing the -dev addon to some module or other. But sometimes you should start over like this:
a. make clean
b. ./configure --prefix=/home/python27
c. make
Starting over never hurts if you are unsure. An important note about step 6. I am not using sudo on this command which means that you will need to have the /home/python27 directory already created with the appropriate ownership.
Don't hesitate to try out ./configure --help |less before building something because there may be interesting options that you could use. One time on a minimal distro I had to do --with-dbmliborder=gdbm:bdb in order to get gdbm working. When you run ./configure, the last few lines will tell you where it put the information that it learned. In the case of Python, Modules/Setup has been useful to figure out how to get a module to build.
Another useful thing is to make clean and then run make >make.out 2>&1 to capture all the output from the full make process. Then, after it is complete, use less or an editor to look for the details on a problem module such as _sqlite. For instance, check all the -I options that are passed to gcc. If the correct include directory is not on the list that would cause a problem. You can edit setup.py to change the list of include directories.
In the past it was more common to have library problems that would be fixed by logging out, logging in again, and running "sudo ldconfig" before doing a complete rebuild.