Pyhunspell installation in virtualnev - linux

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.

Related

YouCompleteMe (ycm), Failed to build regex module

I am trying to install the ycmd plugin for vim (after having ran git submodule update --init --recursive) and I am running into: Failed to build regex module.
After running ./install.py in the "YouCompleteMe" folder, here are the upstream lines that lead to the stated error:
[100%] Linking CXX shared library /home/users/jeremy/.vim/bundle/YouCompleteMe/third_party/ycmd/ycm_core.so
[100%] Built target ycm_core
running build
running build_py
creating /home/users/jeremy/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/regex-build
creating /home/users/jeremy/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/regex-build/regex
copying regex_3/__init__.py -> /home/users/jeremy/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/regex-build/regex
copying regex_3/regex.py -> /home/users/jeremy/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/regex-build/regex
copying regex_3/_regex_core.py -> /home/users/jeremy/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/regex-build/regex
copying regex_3/test_regex.py -> /home/users/jeremy/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/regex-build/regex
running build_ext
building 'regex._regex' extension
creating /home/users/jeremy/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/regex-build/3
creating /home/users/jeremy/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/regex-build/3/temp.linux-x86_64-3.7
creating /home/users/jeremy/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/regex-build/3/temp.linux-x86_64-3.7/regex_3
gcc -pthread -B /home/users/jeremy/anaconda3/compiler_compat -Wl,--sysroot=/ -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/users/jeremy/anaconda3/include/python3.7m -c regex_3/_regex.c -o /home/users/jeremy/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/regex-build/3/temp.linux-x86_64-3.7/regex_3/_regex.o
gcc -pthread -B /home/users/jeremy/anaconda3/compiler_compat -Wl,--sysroot=/ -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/users/jeremy/anaconda3/include/python3.7m -c regex_3/_regex_unicode.c -o /home/users/jeremy/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/regex-build/3/temp.linux-x86_64-3.7/regex_3/_regex_unicode.o
gcc -pthread -shared -B /home/users/jeremy/anaconda3/compiler_compat -L/home/users/jeremy/anaconda3/lib -Wl,-rpath=/home/users/jeremy/anaconda3/lib -Wl,--no-as-needed -Wl,--sysroot=/ /home/users/jeremy/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/regex-build/3/temp.linux-x86_64-3.7/regex_3/_regex.o /home/users/jeremy/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/regex-build/3/temp.linux-x86_64-3.7/regex_3/_regex_unicode.o -o /home/users/jeremy/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/regex-build/regex/_regex.cpython-37m-x86_64-linux-gnu.so
/home/users/jeremy/anaconda3/compiler_compat/ld: /home/users/jeremy/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/regex-build/3/temp.linux-x86_64-3.7/regex_3/_regex.o: unable to initialize decompress status for section .debug_info
/home/users/jeremy/anaconda3/compiler_compat/ld: /home/users/jeremy/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/regex-build/3/temp.linux-x86_64-3.7/regex_3/_regex.o: unable to initialize decompress status for section .debug_info
/home/users/jeremy/anaconda3/compiler_compat/ld: /home/users/jeremy/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/regex-build/3/temp.linux-x86_64-3.7/regex_3/_regex.o: unable to initialize decompress status for section .debug_info
/home/users/jeremy/anaconda3/compiler_compat/ld: /home/users/jeremy/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/regex-build/3/temp.linux-x86_64-3.7/regex_3/_regex.o: unable to initialize decompress status for section .debug_info
/home/users/jeremy/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/regex-build/3/temp.linux-x86_64-3.7/regex_3/_regex.o: file not recognized: file format not recognized
collect2: error: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
Failed to build regex module.
It seems like the /anaconda3/compiler_compat/ld executable is not compatible with the YouCompleteMe/third_party/ycmd/third_party/regex-build/3/temp.linux-x86_64-3.7/regex_3/_regex.o file.
Does someone have an idea of what's going on or what I could try out ?
you can use coc.nvim to do code complement, it works so good and is easy to use.
i tried to build YCM so many times several years before, and in the end, i gave up.
I've found the problem from someone hitting the same kind of issue while trying to compile PyTorch :
"The whole problem lies in the fact that Anaconda distribution comes with its own ld linker that is located in /opt/anaconda/compiler_compat/ and it overshadows system ld residing at /usr/bin.
To fix my error I ran python setup.py clean and then I temporarily renamed Anaconda's ld linker to ld-old to make it invisible during PyTorch installation. Removing -B option from the installation stage could fix it too."
So renaming my anaconda ld linker for the ycm compilation fixed my issue. (I renamed it back afterwards)

nvm: install fails on BSD while building from source

System Info: FreeBSD 11.3-RELEASE-p3, amd64
I have tried using nvm to install node v12.16.2, v10.20.1, and v10.15.3, however it fails building from source (no binary available for pull on BSD) with the same error on all three:
/usr/bin/ld:/usr/home/ifiht/.nvm/.cache/src/node-v12.16.2/files/out/Release/obj.target/tools/v8_gypfiles/libv8_libbase.a: file format not recognized; treating as linker script
/usr/bin/ld:/usr/home/ifiht/.nvm/.cache/src/node-v12.16.2/files/out/Release/obj.target/tools/v8_gypfiles/libv8_libbase.a:1: syntax error
Configure completes successfully:
$>./configure --prefix=/home/ifiht/.nvm/versions/node/v12.16.2 <
INFO: configure completed successfully
gmake -C out BUILDTYPE=Release V=0
and the last command before failure is:
/usr/bin/clang++ -o /usr/home/ifiht/.nvm/.cache/src/node-v12.16.2/files/out/Release/bytecode_builtins_list_generator -pthread -rdynamic -m64 -Wl,--export-dynamic -Wl,--start-group /usr/home/ifiht/.nvm/.cache/src/node-v12.16.2/files/out/Release/obj.target/bytecode_builtins_list_generator/deps/v8/src/builtins/generate-bytecodes-builtins-list.o /usr/home/ifiht/.nvm/.cache/src/node-v12.16.2/files/out/Release/obj.target/bytecode_builtins_list_generator/deps/v8/src/interpreter/bytecode-operands.o /usr/home/ifiht/.nvm/.cache/src/node-v12.16.2/files/out/Release/obj.target/bytecode_builtins_list_generator/deps/v8/src/interpreter/bytecodes.o /usr/home/ifiht/.nvm/.cache/src/node-v12.16.2/files/out/Release/obj.target/tools/v8_gypfiles/libv8_libbase.a -L/usr/local/lib -lexecinfo -Wl,--end-group
I'm out of troubleshooting ideas, if anyone knows how to enable nvm install verbosity that would also help, not sure why the linker is trying to read random .a (assembly?) files??

gcc cannot find standard libraries on mac (when installing python packages from requirements)

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?

how to install MAGMA? I `make install` is run well, but `make test` cause error

I want to install MAGMA in a server(centos) in order to use the GEMM function.
I have installed CUDA and MKL in this server before i install MAGMA, and i check both is run well by runing a cuBLAS example program and a MKL example program.
Before i describe what i haved happened i must point it seem that there is no fortran in this server. So i install MAGMA by follows:
I move make.inc-examples/make.inc.mkl-gcc to ../make.inc
I modify make.inc:
I commented out:
FORT = gfortran
FFLAGS = -O3 $(FPIC) -DNDEBUG -DADD_ -Wall -Wno-unused-dummy-argument
F90FLAGS = -O3 $(FPIC) -DNDEBUG -DADD_ -Wall -Wno-unused-dummy-argument -x f95-cpp-input
and remove -lgfortran in
LIB = -lmkl_gf_lp64 -lmkl_gnu_thread -lmkl_core -lpthread -lstdc++ -lm -lgfortran
and i also set MKLROOT=/home/lixin/intel/mkl and CUDADIR=/usr/local/cuda in this file.
I run make install prefix=/home/lixin/install/, it seem well and i haven't see any error tag.
I run make test, it cause error soon:
It turn out this is a bug in testing program.Thank for #Ignacio Vazquez-Abrams point to this.
I have post this problem in MAGMA Forum, then i got a fix tar file, and this problem had solved.
If you also meet this problem, you can see this post

Compiling program with Open Source libFTDI

I use Asus router (based on ARMv7 proc) with Advanced Tomato installed
on it as my ARMv7 developer platform. I install compiler (gcc - 5.4.0-1)
plus dependencies and libFTDI (libftdi1 - 1.3-1) from OpenWRT Linux
repo. OpenWRT does not provide libftdi-dev so I copied ftdi.h file from libFTDI download page to /opt/include directly. I try to compile program taken directly from libFTDI samples. The
compiler command is:
gcc -v -Wl,-rpath=/opt/usr/local/lib -Wl,--dynamic-linker=/opt/lib/ld-linux.so.3 -L/opt/lib -O2 -pipe -march=armv7-a -mtune=cortex-a9-fno-caller-saves -mfloat-abi=soft -l ftdi1 d.c -o d
But compilation fails because:
/opt/bin/ld: cannot find -lftdi1
But there is /opt/usr/local/lib/libftdi1.so linked to libftdi1.so.2
My LD_LIBRARY_PATH looks like this:
/lib:/usr/lib:/usr/local/lib:/opt/lib:/opt/usr/lib:/opt/include:/opt/usr/local/lib:/opt/usr/include
So what the problem is?
I dont know why (probably bug) but for compiler taken from OpenWRT repo, MUST have wanted library in /opt/lib. So simply copy libftdi1.so.2.3.0 file and linking it to libftdi1.so resolved problem. That means that it does not use correctly LD_LIBRARY_PATH variable. Finally compilation command looks like this:
gcc -v -Wl,-rpath=/opt/usr/local/lib -Wl,--dynamic-linker=/opt/lib/ld-linux.so.3 -L/opt/lib -O2 -pipe -march=armv7-a -mtune=cortex-a9 -fno-caller-saves -mfloat-abi=soft -l ftdi1 arco.c -o arco
From my point of view - topic closed

Resources