I am trying to install scikit-learn 19.1 due to some project requirements and it's producing the following error:
1 warning and 15 errors generated.
error: Command "g++ -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -arch x86_64 -g -I/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/numpy/core/include -I/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/numpy/core/include -I/Library/Frameworks/Python.framework/Versions/3.8/include/python3.8 -c sklearn/cluster/_dbscan_inner.cpp -o build/temp.macosx-10.9-x86_64-3.8/sklearn/cluster/_dbscan_inner.o -MMD -MF build/temp.macosx-10.9-x86_64-3.8/sklearn/cluster/_dbscan_inner.o.d" failed with exit status 1
Python 3.8 is not officially supported by NumPy or scikit-learn yet. We strongly suggest you stick with python 3.7 for now, until you see a 3.8 designation in the "Programming Language" section of the PyPI numpy page (probably several weeks) or until an Anaconda release with Python 3.8 is available (probably several months)
So it looks like it might be the underlying dependencies just not working with 3.8 yet. I actually had a similar issue with another package last week. You will probably have luck if you get a 3.7.5 install. Make sure you get the right platform (x86 for 32-bit, x64 for 64 bit) and make sure you check the box to add it to your path.
Related
I'm trying to build a c module in MacOS. The build fails during the linker process with the error:
ld: warning: object file (build/temp.macosx-11.1-x86_64-3.7/pparser.o) was built for newer macOS version (11.1) than being linked (11.0)
I realize this is just a warning but the resulting so file fails in import to a python script. I'm doing the build with the following setup.py
from distutils.core import setup, Extension
setup(name='pparser', version='1.0', \
ext_modules=[Extension('pparser',
['pparser.cpp'],
extra_compile_args = ["-Wno-nullability-completeness",
"-Wno-undef-prefix",
"-I/usr/local/opt/flex/include",
"-I/usr/local/opt/bison/include",
"-std=gnu++14"])])
What's odd is that I can capture the clang invocation and run it myself at the command line with the verbose option
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -bundle -undefined dynamic_lookup -L/Users/john/.pyenv/versions/3.7.9/lib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk -std=gnu++14 -L/usr/local/opt/readline/lib -L/Users/john/.pyenv/versions/3.7.9/lib -L/usr/local/opt/tcl-tk/lib build/temp.macosx-11.1-x86_64-3.7/pparser.o -o build/lib.macosx-11.1-x86_64-3.7/pparser.cpython-37m-darwin.so --verbose
and I see the following:
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -dynamic -arch x86_64 -bundle -platform_version macos 11.0.0 11.3 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk -undefined dynamic_lookup -undefined dynamic_lookup -o build/lib.macosx-11.1-x86_64-3.7/pparser.cpython-37m-darwin.so -L/Users/john/.pyenv/versions/3.7.9/lib -L/usr/local/opt/readline/lib -L/Users/john/.pyenv/versions/3.7.9/lib -L/usr/local/opt/tcl-tk/lib build/temp.macosx-11.1-x86_64-3.7/pparser.o -lc++ -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/12.0.5/lib/darwin/libclang_rt.osx.a
I suspect that the problem is the ld switch -platform-version macOS 11.0.0 11.3 but where does that come from? It's not in the setup file or in the command line that I typed.
My set up is brew python 3.7.9 in a pyenv virtual environment.
Any help on understanding where python setup is pulling command line options from would be quite helpful.
After more digging, I found the answer here:
Customizing the compiler and linker used by setuptools
It seems that CPython creates a sysconfig file containing all the environment variables used to compile it. These are then used by python when a setup file is built.
You can review these variables in python:
import distutils.sysconfig
distutils.sysconfig.get_config_var()
The author goes on to describe how to override any variable desired.
Does anyone know how to solve this problem?
pyenv build fails. Trying to integrate spark scala with jupyter notbook as described hereenter link description here
➜ ~ pyenv install 3.8.2
python-build: use openssl#1.1 from homebrew
python-build: use readline from homebrew
Downloading Python-3.8.2.tar.xz...
-> https://www.python.org/ftp/python/3.8.2/Python-3.8.2.tar.xz
Installing Python-3.8.2...
python-build: use readline from homebrew
python-build: use zlib from xcode sdk
^D
BUILD FAILED (OS X 11.2.1 using python-build 20180424)
Inspect or clean up the working tree at /var/folders/_v/qvsxvlw51rxb43z929hyv45w0000gn/T/python-build.20210222233923.72853
Results logged to /var/folders/_v/qvsxvlw51rxb43z929hyv45w0000gn/T/python-build.20210222233923.72853.log
Last 10 log lines:
extern int _NSGetExecutablePath(char* buf, uint32_t* bufsize) __OSX_AVAILABLE_STARTING(__MAC_10_2, __IPHONE_2_0);
^
clang -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -Werror=implicit-function-declaration -I./Include/internal -I. -I./Include -I/usr/local/opt/readline/include -I/usr/local/opt/readline/include -I/Users/quais/.pyenv/versions/3.8.2/include -I/usr/local/opt/readline/include -I/usr/local/opt/readline/include -I/Users/quais/.pyenv/versions/3.8.2/include -DPy_BUILD_CORE_BUILTIN -DPy_BUILD_CORE_BUILTIN -I./Include/internal -c ./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c:9197:15: error: implicit declaration of function 'sendfile' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
ret = sendfile(in, out, offset, &sbytes, &sf, flags);
^
1 error generated.
make: *** [Modules/posixmodule.o] Error 1
make: *** Waiting for unfinished jobs....
1 warning generated.
➜ ~
Saving session...completed.
Deleting expired sessions...none found.
[Process completed]
I could solve this by getting an older version the environment. Apparently the latest version is not supported even if i have the 12+ version of Xcode
pyenv install 3.7.9
I am having an issue due to my gcc missing standard libraries.
copying blpapi/schema.py -> build/lib.macosx-10.7-x86_64-3.7/blpapi
running build_ext
building 'blpapi._internals' extension
creating build/temp.macosx-10.7-x86_64-3.7
creating build/temp.macosx-10.7-x86_64-3.7/blpapi
gcc -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/anaconda3/envs/invtools/include -arch x86_64 -I/anaconda3/envs/invtools/include -arch x86_64 -I/usr/local/lib/blpapi_cpp_3.8.1.1/include -I/anaconda3/envs/invtools/include/python3.7m -c blpapi/internals_wrap.cxx -o build/temp.macosx-10.7-x86_64-3.7/blpapi/internals_wrap.o
warning: include path for stdlibc++ headers not found; pass '-std=libc++' on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found]
blpapi/internals_wrap.cxx:3101:10: fatal error: 'stdexcept' file not found
#include <stdexcept>
^~~~~~~~~~~
1 warning and 1 error generated.
error: command 'gcc' failed with exit status 1
I had a different issue initially. It was something about cannot find type uint8_t. And someone suggested to delete files in: /usr/local/include/. And that causes the above now. It is because there are no standard libraries now. I installed this /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg and now I have standard lib in /usr/include. Which I copied to /usr/local/indclude/ to no avail. brew link gcc tells me:
Warning: Already linked: /usr/local/Cellar/gcc/8.2.0
To relink: brew unlink gcc && brew link gcc
How do I resolve this issue?
According to the README in the Python 3.4.2 source package compilation on Cygwin should be as easy as this:
./configure
make
make test
sudo make install
However, the make command fails after a while giving me this output (i have gcc 3.4.4):
$ make
gcc -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I. -IInclude -I./Include -DPy_BUILD_CORE -c ./Modules/signalmodule.c -o Modules/signalmodule.o
...
./Modules/signalmodule.c: In function ‘fill_siginfo’:
./Modules/signalmodule.c:744:5: error: ‘siginfo_t’ has no member named ‘si_band’
Makefile:1645: recipe for target `Modules/signalmodule.o' failed
make: *** [Modules/signalmodule.o] Error 1
I guess there are some dependencies that I need to compile?
Python does not compile out of the box without additional patches.
I was able to compile Python 3.4.2 on cygwin with the following 2 patches:
http://bugs.python.org/file34693/cygwin_si_band.patch
http://bugs.python.org/file28934/0001-CYGWIN-issue13756-Python-make-fail-on-cygwin.patch
I have a problem with installation of pyhunspell bindings for hunspell library in python 3.2 virtualenv. I downloaded hunspell from here. I issued ./configure and make and it run all right. I avoided however to do make install because my purpose is to install it on virtualenv on a web server, where I have no root permissions.
Thus I downloaded pyhunspell bindings and unzipped it to the directory, where hunspell is made. I modified include_dir path in setup.py by adding correct destination and applied the patch which allows to build pyhunspell with Python 3. Then I ran python setup.py install (having activated the target virtualenv before), but I got this:
$ python setupy.py install
running install
running build
running build_ext
building 'hunspell' extension
gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -D_FORTIFY_SOURCE=2 -g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -fPIC -D_LINUX -I./src/hunspell -I/usr/include/hunspell -I/usr/include/python3.2mu -c hunspell.c -o build/temp.linux-x86_64-3.2/hunspell.o -Wall
creating build/lib.linux-x86_64-3.2
gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro build/temp.linux-x86_64-3.2/hunspell.o -lhunspell-1.2 -o build/lib.linux-x86_64-3.2/hunspell.cpython-32mu.so
/usr/bin/ld: cannot find -lhunspell-1.2
collect2: error: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
It seems that linker cannot link something because it looks for it in system path, while I didn't install the library in the system. Can someone wiser than me in the arcana of C devise any workaround to this issue?
I'll add that I have no access to the real server yet, but I know it will have the system pretty much similar to my local one (Debian 7.0 Wheezy), so I decided to give it a try before I actually log in to the server. Is it possible that the library compiled on my computer would work also on the server, assuming it would also be some (stable probably) version of Debian?
There's no need to build Hunspell. Install the Wheezy packages libhunspell-1.3-0 and libhunspell-dev. It should work with HunSpell 1.3. Just modify setup.py to use libraries = ['hunspell'].
FYI, the posted patch has a problem. It adds the methods of HunSpell as module functions. These receive the module as the first argument instead of the expected HunSpell instance. For example, if you call hunspell.spell, the process will probably segfault when it tries to use self->handle. You should fix the PyModuleDef to get rid of these mal-functions. Change line 273 of hunspell.c to use NULL instead of HunSpell_methods.