I am attempting to get a topojson file with US state names & ids. Using http://www.tnoda.com/blog/2013-12-07 for reference.
I read that it was recommended we generate our own topojson files and I have been attempting to get ogr2ogr working on MAC OSX v 10.7.5.
Running ogr2ogr in the command line gives:
dyld: Library not loaded: /usr/local/lib/libjpeg.8.dylib
Referenced from: /usr/local/bin/ogr2ogr
Reason: Incompatible library version: ogr2ogr requires version 13.0.0 or later, but libjpeg.8.dylib provides version 9.0.0
Trace/BPT trap: 5
I am not sure what its complaining about. Most recent version of libjpeg is not 13 but 9. I thought it might want version 8 instead. But I still get the same error after following installation instructions from http://ijg.org/files/jpegsrc.v8a.tar.gz.
Any help would be very much appreciated. Thank you!
P.S: My end goal is to get a map like this http://bl.ocks.org/mbostock/4060606 but I need the 2 letter state names in the json since thats what I have in my data.
Fixed this! uninstall gdal and reinstall it again.
brew uninstall gdal
brew install gdal -> Did not work. it wanted to link jpeg libtiff
brew link jpeg libtiff -> It might tell you to remove certain files but its simple.
brew install gdal -> worked!
ogr2ogr -> prints usage instructions instead of some cryptic error
I guess my installation of libjpeg had lingering incompatible files. Not sure.
Related
vincens#VMAC: python3
dyld: Library not
loaded:/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
Referenced from:
/Library/Frameworks/Python.framework/Versions/3.6/Resources/Python.app/Contents/MacOS/Python
Reason: image not found
[1] 25278 abort python3
python3 env is not used when I update my Mac to the latest version. How can I solve it?
This worked for me with the same issue.
Check if you have multiple Python3.x versions installed. In my case I had Python3.6 and Python3.9 installed. brew uninstall python3 did not remove Python3.6 completely.
I was able to call Python3.9 from Terminal by explicitly running python3.9 instead of python3, which led me to believe the issue was caused by ambiguity in which Python3.x resource was to be used.
Manually deleted /Library/Frameworks/Python.framework/Versions/3.6 resulted in Python3 running as expected.
hint:
It may be sufficient to remove /Library/Frameworks/Python.framework/Versions/3.6 from your PATH environment variable.
Check in the location:
/usr/bin/python3
If you can invoke python3 interpreter from this location without any issues, copy this to
/usr/local/bin/python3
I upgraded to macOS Big Sur and had faced the same issue. I was not able to open Python interpreter from terminal and the Python version inside Library/Frameworks/Python.framework/Versions/3.6 was also being pointed to Python2.7.
Later, I found python3 in location /usr/bin/python3 working fine for me. I also tried creating a symlink for python3 to the above path but didn't work.
That's becuase you have installed both python 3.6 from system library & python3.9 from other source like brew and there are something wrong with the python in lower version. Please manually delete the python within /Library/Frameworks. sudo rm -rf /Library/Frameworks/Python.framework/Versions/3.6 this command works for me.
I encountered this same problem on Step 1 of PyCharm's Create a Django project documentation.
I had previously set up Python on my Mac following these instructions. Can't promise this solution will work for everyone, but maybe if someone's Python was set up similar to mine the following solution that worked for me might help you...
Open Terminal
which python3
Copy the directory given to you... (For me it was /Users/foo/.pyenv/bar/python3)
When creating your new Django project in PyCharm (Professional Edition), set your base directory to the one received from which python3
Create your project
My case
Deleted Xcode (Maybe some folders are accidentally deleted like /Library/Frameworks/...
Also installed Python with anaconda.
My solution
Reinstall Xcode
Followed this to remove anaconda then everything works fine
I am trying to install pysam.
After excecuting:
python path/to/pysam-master/setup.py build
This error is produced:
unable to execute 'x86_64-conda_cos6-linux-gnu-gcc': No such file or directory
error: command 'x86_64-conda_cos6-linux-gnu-gcc' failed with exit status 1
There are similar threads, but they all seem to address the problem assumig administriator rights, which I do not have. Is there a way around to install the needed files?
DISCLAIMER: This question derived from a previous post of mine.
manually installing pysam error: "ImportError: No module named version"
But since it might require a different approach, I made it a question of its own.
You can also receive the same error while installing some R packages if R was installed using conda (as I had).
Then just install the package by executing: conda install gxx_linux-64 to have that command available.
Source:
https://github.com/RcppCore/Rcpp/issues/770#issuecomment-346716808
It looks like Anaconda had a new release (4.3.27) that sets the C compiler path to a non-existing executable (quite an embarrassing bug; I'm sure they'll fix it soon). I had a similar issue with pip installing using the latest Miniconda, which I fixed by using the 4.3.21 version and ensuring I was not doing something like conda update conda.
See https://repo.continuum.io/miniconda/ which has release dates and versions.
It should now be safe to update conda. This is fixed in the following python packages for linux-64:
python-3.6.2-h0b30769_14.tar.bz2
python-2.7.14-h931c8b0_15.tar.bz2
python-2.7.13-hac47a24_15.tar.bz2
python-3.5.4-hc053d89_14.tar.bz2
The issue was as Jon Riehl described - we (Anaconda, formerly Continuum) build all of our packages with a new GCC package that we created using crosstool-ng. This package does not have gcc, it has a prefixed gcc - the missing command you're seeing, x86_64-conda_cos6-linux-gnu-gcc. This gets baked into python, and any extension built with that python goes looking for that compiler. We have fixed the issue using the _PYTHON_SYSCONFIGDATA_NAME variable that was added to python 3.6. We have backported that to python 2.7 and 3.5. You'll now only ever see python using default compilers (gcc), and you must set the _PYTHON_SYSCONFIGDATA_NAME to the appropriate filename to have the new compilers used. Setting this variable is something that we'll put into the activate scripts for the compiler package, so you'll never need to worry about it. It may take us a day or two to get new compiler packages out, though, so post issues on the conda-build issue tracker if you'd like to use the new compilers and need help getting started.
Relevant code changes are at:
py27: https://github.com/anacondarecipes/python-feedstock/tree/master-2.7.14
py35: https://github.com/anacondarecipes/python-feedstock/tree/master-3.5
py36: https://github.com/anacondarecipes/python-feedstock
The solution that worked for me was to use the conda to install the r packages:
conda install -c r r-tidyverse
or r-gggplot2, r-readr
Also ensure that the installation is not failing because of admin privileges.
It will save you a great deal of pain
After upgrading Golang to 1.19.1, I started to get:
# runtime/cgo
cgo: C compiler "x86_64-conda-linux-gnu-cc" not found: exec: "x86_64-conda-linux-gnu-cc": executable file not found in $PATH
Installing gcc_linux-64 from the same channel, has resolved it:
conda install -c anaconda gcc_linux-64
Somewhere in your $PATH (e.g., ~/bin), do
ln -sf $(which gcc) x86_64-conda_cos6-linux-gnu-gcc
Don't put this in a system directory or conda's bin directory, and remember to remove the link when the problem is resolved upstream. gcc --version should be version 6.
EDIT: I understand the sentiment in the comments against manipulating system paths, but maybe we can use a little critical thinking for the actual case in hand before reciting doctrine. What actually have we done with the command above? Nothing more than putting an executable (symlink) called x86_64-conda_cos6-linux-gnu-gcc in one's personal ~/bin directory.
If putting something in one's personal ~/bin directory broke future conda (after it fixes the C compiler path to point to gcc it embeds), then that would be a bug with conda. Would the existence of this verbosely named compiler mess with anything else? Unlikely either. Even if something did pick it up, it's just your system gcc after all...
In fc17 the openssl version is 1.0.0k while in fc18 the openssl version is 1.0.1e
In the following link we can see that this symbol was added to 1.0.1 but I can not understand how to fix these errors
There was a problem importing one of the Python modules required to run yum. The error leading to this problem was:
/lib/libssh2.so.1: symbol EVP_aes_128_ctr, version libcrypto.so.10 not defined in file libcrypto.so.10 with link time reference
and
git-remote-https: /tmp/_MEIo4w334/libcrypto.so.10: no version information available (required by /lib/libssh2.so.1)
git-remote-https: relocation error: /lib/libssh2.so.1: symbol EVP_aes_128_ctr, version libcrypto.so.10 not defined in file libcrypto.so.10 with link time reference
Any idea what's wrong or how to fix?
The issue is with pyinstaller. yum and git commands work perfectly fine when run from cli. These commands are called from a binary created by pyinstaller from a python script. When I use the script directly it works fine hence the problem is pyinstaller.
Edit:
In fact the problem wasn't even with pyinstaller, it was the packaging. I created the binary using pyinstaller on fc17 and used the binary on fc18, this was the root cause to the problem above. If I build the binary on fc18, I can run it with no problem on fc18.
I'm trying to install hdbc-sqlite with Cabal in Windows. I found some help from this nice post, but the installation of Sqlite3's dll and def files failed on a package called lifted-base-0.1.1 because of an unrecognized option --disable-benchmarks.
Maybe I could fix this problem by modifying the installer's source code and removing this unrecognized option, and then manually installing the package, if manual installations are possible? Or is there a less tedious solution?
Did you try cabal update?
I would first try a more recent version (of lifted-base) like 0.1.2 or 0.2. Then I would manually download the tar file and use this (change the path in the import command).
Also try to upgrade your GHC / Haskell platform, you apparently describe a known issue.
I'm trying to run some precompiled code (source code is not available) on Ubuntu, which requires openCV to be installed. I installed the latest version of openCV (from the SVN) yesterday, and installed it according to the debian install guide on the openCV website (cmake -> make -> sudo make install) and everything seemed to go fine.
Now when I try to run the precompiled code, i'm getting the error "./stipdet: error while loading shared libraries: libcxcore.so.2: cannot open shared object file: No such file or directory"
It seems that other people who are having a similar problem managed to fix it by moving libcxcore.so.2 from the opencv lib folder to somewhere else, but I don't have libcxcore.so.2 in my opencv folder at all. I do see libopencv_core.so.2.2 in there among other things. Could it be that the name of libcxcore has been changed in the latest version of openCV? Or did I not install it correctly?
btw: running locate libcxcore in the terminal returns nothing
I had the same problem and I solved the problem by installing libcv, libcvaux, libhighgui and their -dev libraries from Synaptics. But the program dependent on the libcv.so.2 shared libraries but Synaptics installs libcv.so.4.0.0. So I created symbolic links for every installed library by running command:
sudo ln -s /usr/lib/libcxcore.so.4.0.0 /usr/lib/libcxcore.so.2
and so on for every library that the program needs. Now it is working fine for me.
I had the same problem working on STIP and OpenCV 2.2.
To solve the issue, just create symbolic links as below. It works for me.
libcvaux.so.2 -> /usr/lib/libopencv_video.so.2.2.0
libcv.so.2 -> /usr/lib/libopencv_legacy.so.2.2.0
libcxcore.so.2 -> /usr/lib/libopencv_core.so.2.2.0
libhighgui.so.2 -> /usr/lib/libopencv_highgui.so.2.2.0
libml.so.2 -> /usr/lib/libopencv_ml.so.2.2.0
a small addition to (correct) answer by Zifei Tong:
One needs to make the symbolic links AND also needs to export LD_LIBRARY_PATH
for bash, it is :
libcvaux.so.2 -> /usr/lib/libopencv_video.so.2.2.0
libcv.so.2 -> /usr/lib/libopencv_legacy.so.2.2.0
libcxcore.so.2 -> /usr/lib/libopencv_core.so.2.2.0
libhighgui.so.2 -> /usr/lib/libopencv_highgui.so.2.2.0
libml.so.2 -> /usr/lib/libopencv_ml.so.2.2.0
export LD_LIBRARY_PATH="path to symbolic links' directory"
This error is because they change the library names after openCV 2.2, however STIP depends on previous libraries.
You just need to set few symbolic links and it will work. The following link will solve your problem
http://web.michaelchughes.com/how-to/install-stip-software-with-opencv-v2
Yes, the library names have changed. Try OpenCV 2.1 or 2.0 (it changed either for 2.2 or 2.1 i think). If your precompiled code is for ubuntu, why didn't you install the ubuntu opencv package?