I've been trying to understand this situation:
I want to use python packages in Anaconda 3 that requires glibc 2.14. As Centos 6.x only uses glibc 2.12 I've compiled glibc 2.14 and installed to /opt/glibc-2.14.
I'm installing Anaconda3. The test I run looks like this:
With system default glibc it works:
/opt/anaconda3/bin/python -c "import pandas"
but with compiled glibc
export LD_LIBRARY_PATH=/opt/glibc-2.14/lib/:$LD_LIBRARY_PATH
/opt/anaconda3/bin/python -c "import pandas"
it works on some machines... I installed over 20 VM and on some machines it works always and on some it never works and I receive: Segmentation fault (core dumped). On most of the machines it doesn't work.
Does anyone have any idea why this strange situation occures? Or maybe experienced this problems with
Does anyone have any idea why this strange situation occures
As this answer explains, what you are doing is not supposed to work: you have a mismatch between ld-linux and libc.so.6.
After some more investigating I've noticed that assigning more memory to lab machines (from 2/4 GB to 6 and more) make the segmentation fault error to go away. However problem still exist on production machine with 32 GB of RAM. Really strange.
Right now I found workaround which were the new python packages from anaconda that are compatibile with glibc 2.12 (become available few days ago) and packages' dependencies also does not require newer glibc.
#Employed Russian:
Thanks, but probabaly not the problem with Multiple glibc libraries on a single host. In my case Python works with additional glibc. The problem is that the segmentation fault shows up on random machines while only using new glibc. Also I'm using other Python packages that requires glibc 2.14 to work, so I'm aware which version of glibc I'm using at the moment.
Also if there were some kind of mismatch in libraries then it shouldn't work at all (...probably).
Also as I mentioned at the beginning I've noticed that the problem is related to memory (still not sure what is happening with 32 GB of RAM machine).
One more thing: I'm not compiling python packages, so changing of compilator options od 'myapp' (python package) is not an option.
Appreciate your answers though.
Related
I recently purchased a new mac laptop with the M1 core. I've previously done work using tensorflow, and am trying to continue with my new laptop. I'm aware that apple has a tensorflow_macos version of tensorflow, but unfortunately for my project I need higher order derivatives, which the fork is not currently capable of doing. Is there a way to run the non_mac specific version of tensorflow on a M1?
If I attempt to import tensorflow from an arm terminal, I get the error:
python3
import tensorflow
zsh: illegal hardware instruction python3
The same happens if I run from a Rosetta terminal.
I've also tried running from PyCharm (with a Python 3.8 virtual environment), but I receive a different problem on trying to import tensorflow:
Process finished with exit code 132 (interrupted by signal 4: SIGILL)
I have python3.8.5 installed. I've seen on other related questions that there should be two versions of python3 installed by default on mac (arm and x86_64), but it looks like I only have one version:
file $(which python3)
/Users/xxx/opt/miniconda3/bin/python3: Mach-O 64-bit executable x86_64
I'm inexperienced when it comes to handling different core architectures, so any advice would be appreciated. I'm happy to provide clarification for any specifics.
I'm working on a project built with Cython and have been having some interesting installation issues on some particular systems. The problem boils down to either a mismatch in Mac OS versions, or a mismatch in my understanding of Mac OS versions.
When installing a Cython library on my system, the compilation log shows that I am using Mac OS version 10.12, even though my system tells me I am on 10.13. An excerpt of the compilation log is below:
creating build/temp.macosx-10.12-x86_64-3.6
This is not a problem for me, but another user is having trouble where their system release on 10.13, but their compilation is showing 10.7 (which requires some other work arounds).
Is it possible to update this build system? Or is there something about Mac OS that I'm misunderstanding?
Is there a way to tell from a Python script which build libraries will be used?
Thank you!
Edit:
Output of platform information:
>>> python -c "import platform; print(platform.mac_ver())"
('10.13.6', ('', '', ''), 'x86_64')
>>> python -c "import distutils.util; print(distutils.util.get_platform())"
macosx-10.12-x86_64
My context
A similar issue came up with Big Sur (macOS 10.16), python3.6, and cython.
Checking the build directory of cython (.pyxbld) I find temp.macOSX-10.7 builds and files, which apparently is incompatible with 10.16.
Some Explanations why this is going on
Under the hood cython uses distutils to determine the platform version (as opposed to other things). https://github.com/python/cpython/blob/master/Lib/distutils/util.py So then what's up with distutils?
After a lot of searching (including this post), I came across a really interesting and good post (although from 2014) that explains this phenomenon.
https://lepture.com/en/2014/python-on-a-hard-wheel
Basically, it has to do with how distutils was build and that it has hard-coded platform tags... (this also applies to the wheel files).
Solution (kinda)
It seems that the solution is to :
reinstall python (and then all packages)
make sure that python -c "import distutils.util; print(distutils.util.get_platform())" macosx-10.12-x86_64 outputs a correct version.
Edit
Apparently On Big Sur with Anaconda this solution does not work yet... (work in progress will update if solution on Anaconda will work) [Fri 20 Nov 2020]
So I spent a whole day trying to find out the solution for this. I am trying to install graph-tool on my machine with 14.04 OS. Initially I was unable to succeed because I didn't have gcc 5 on my machine. After installing it, I am trying the following:
./configure CXX='g++5'
and I get the following error:
===========================
Using python version: 2.7.6
===========================
checking for boostlib >= 1.54.0... configure: We could not detect the boost libraries (version 1.54 or higher). If you have a staged boost library (still not installed) please specify $BOOST_ROOT in your environment and do not give a PATH to --with-boost option. If you are sure you have boost installed, then check your version number looking in <boost/version.hpp>. See http://randspringer.de/boost for more documentation.
checking whether the Boost::Python library is available... no
configure: error: No usable boost::python found
I see no solution on the mailing list of graph-tool or stackoverflow about this problem. I would be really grateful if somebody could help me with this.
Thanks in advance.
In Debian, the libraries are almost always split in two packages: One
containing the shared object and another one with "-dev" suffix which
contains the header files. For cairomm you need to install the
libcairomm-1.0-dev package, in addition to libcairomm-1.0.
And cairo support is optional. If you want to disable it, just pass
the --disable-cairo to the configure script.
Source: https://lists.skewed.de/pipermail/graph-tool/2013-November/001094.html
There are some issues with the boost package on ubuntu 14.04 and some of the graph-tool functions (see graph-tool - k-shortest path - boost::coroutine was not found at compile-time and http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/Debian-package-and-boost-at-compile-time-td4026383.html ). At current it seems neccessary to compile boost from source until a newer version of boost is uploaded to the repository in order for graph-tool to work fully.
Once this bug is fixed (https://bugs.launchpad.net/ubuntu/+source/boost1.54/+bug/1529289) it will no longer be a problem.
Is it possible to have IPython (0.12) installed on the same
system with two different versions of Python (v 2.7 and 3.2)? Currently I have both versions of Python running happily on my system.
I am using two machines, one with Windows 7 64-bit, the other XP SP2 32-bit, and both have Python 2.7.2 and 3.2 installed. I have been using IPython with Python 2.7 w/o any problems for a while on both.
Now I would like to have 3.2 available too with IPython, but when I try to run the binary windows IPython installer I get this error toward the end of the install:
*** run_installscript: internal error 0xFFFFFFFF ***
and no shortcuts/entries into Start Menu etc are created.
(I ran the install as adminstrator under Win 7) I am running into the same problem with XP and Win 7.
After poking around the net and SO for a while I saw references for
getting setuptools. Unfortunately, there's no version for Python 3.x
but it was suggested to use distribute.py instead which I ran and
installed. I am not sure how to proceed next. And I'm not even sure it
is possible to do this (though I think it is :)
Any suggestions?
UPDATE: There was a problem with import readline not working with Python 3.2.3, but I was able to fix it by downloading pyreadline-2.0-dev1.win32.exe which works with Python 3.2.3 .. the above problem remains unfortunately.
Ok, here's my solution to get IPython 0.12.1 to work with both Python ver
2.7.x and 3.2.x on the same system (ie. under Windows 7 64 bit and XP SP2 32 bit). It's not
perfect, but works, and hopefully will help others. Where I am showing directories they refer to XP (but should be adjusted accordingly for Windows 7)
Steps for both:
Install both versions of Python via the binary windows installer provided at
Python.org
Install this version of pyreadline pyreadline-2.0-dev1.win32.exe which works
for both versions of Python (I could not get the widely available version 1.7 to work with Python 3.2.x)
I am not sure if distribute.py is necessary, I'd skip it on the
first try.
Download ipython-0.12.1.zip file and extract it. Place it under your Programs directory and cd into it (I'll call this the ipython_dir) [I tried the binary installer numerous times without success]
For Python 3.2 (easier)
In the ipython_dir:
c:\python32\pyton.exe setup.py install
will create ipython3.exe in c:\python32\Scripts that can be used to
fire up iPython
For Python 2.7 (a bit odd)
The above method failed. However, it is possible to start IPython from the ipython_dir with
c:\python27\python.exe ipython.py
I can't explain why this is so, but since I use Console2 I can hide
these two ways of starting IPython.
Summary:
To start IPython with v 2.7.x of Python:
c:\python27\python.exe "C:\Program Files..\ipython_dir\ipython.py"
To start IPython with v 3.2.x of Python:
c:\python32\Scripts\python3.exe
That was a lot of work and took most of the day, so I hope posting the steps above
will save someone else a lot of time (and help me remember what I have to do next time I struggle with this)
Thanks everyone for their suggestions.
Addendum: None of the above resulted in shortcuts or entries in the Start/Program Menus. Shortcuts can be created manually, or in my case aren't necessary since I'm using a special shell (Console2) to run IPython.
The first question in the iPython FAQ titled "Running IPython against multiple versions of Python" may help.
I'm trying to get node.js running on Windows 7. I have no experience with Linux so I've just been blindly following instructions from tutorials I've found, but I'm still unable to build node.js.
What I did:
Install Cygwin - the entirety
Attempt to build node.js
This is the error I first got:
I then followed the commands of two other similar sites and they all resulted in this error (could getting several version of node have caused me more problems? I'm completely clueless on this).
I read somewhere that the Windows version of Python could be causing the problem so I uninstalled my Python 2.7 and added C:\cygwin\bin to the PATH.
That still didn't work and I read somewhere else that I'm supposed to rebaseall so I tried that, but I also got an error for that:
That's where I'm at now. Have any steps I've taken exacerbated the situation?
Add -e '/\/sys-root\/mingw\/bin/d' at line 110 in /bin/rebaseall file.
Then re-run rebaseall -v and you shouldn't get the error anymore.
See this pretty helpful blog posting - Node on CygWin doesn't work for Node v0.2.5. Use the latest v0.4.0 version instead.
Also consider the post's recommendation of compiling against MinGW instead of in CygWin.
First of all, why did you check out such an old release v0.2.5? When I did it a few weeks ago I just took the latest and ended up with 0.5.0pre, but it would also be reasonable to specify v0.4.3. For instance, type git clone git://github.com/joyent/node.git to download node, and then:
cd node
./configure
make install
Secondly, do not rebase by running ash from the CYGWIN shell. Instead, shutdown all Cygwin processes, then use Windows explorer to open the ash.exe binary. Since I have a Windows 7 system without node.js, I decided to follow my instructions and build. Not so easy. I ran into some wierd dll issues that all went away when I ran ./rebaseall followed by ./perlrebase from the ash prompt. It seems that rebaseall is not sufficient anymore.
Thirdly, there is a message that makes it sound like you don't have a C compiler. Some googling will lead you to sites telling which Cygwin packages you need, but at minimum install the g++ compiler and that should pull in C as a dependency.
When I did this I simply ran configure and every time there was an error, installed one more Cygwin package to supply the missing piece. Even OpenSSL is available.
What I just found is remove the windows based install of Python. After uninstalling this, everything is peachy.
I like cygwin a lot -- but recent releases have become pretty unreliable. Some packages just wont build, and some "standard" apps dont work e.g. gvim's "save as" bombs out on my installation.
A possible solution would be run one of the better Linux distributions (ubuntu, fedora, suse etc.) either as a virtual machine or a dual boot setup and do the build inside linux.