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)
Related
I have installed the Contiki OS sources, and the ARM GCC compiler by doing brew install arm-none-eabi-gcc. However, when I try to run the hello world example in Contiki's example folder using the command make TARGET=srf06-cc26xx BOARD=sensortag/cc2650 hello-world.bin CPU_FAMILY=cc26xx, I get the following error message:
CC ../../cpu/cc26xx-cc13xx/lib/cc26xxware/startup_files/ccfg.c
arm-none-eabi-gcc: error: unrecognized -march target: core2
arm-none-eabi-gcc: note: valid arguments are: armv4 armv4t armv5t armv5te armv5tej armv6 armv6j armv6k armv6z armv6kz armv6zk armv6t2 armv6-m armv6s-m armv7 armv7-a armv7ve armv7-r armv7-m armv7e-m armv8-a armv8.1-a armv8.2-a armv8.3-a armv8.4-a armv8.5-a armv8-m.base armv8-m.main armv8-r iwmmxt iwmmxt2
arm-none-eabi-gcc: error: missing argument to '-march='
arm-none-eabi-gcc: error: unrecognized command line option '-mssse3'
make: *** [obj_srf06-cc26xx/ccfg.o] Error 1
I triple-checked that the ARM GCC compiler is accessible from the terminal by doing arm-none-eabi-gcc --version, and I can see that it is properly installed:
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
So I am really not sure what might be wrong here. Can anyone help?
My operating system is macOS Mojave Version 10.14.6.
UPDATE: The makefile is given in the example folder (from contiki):
CONTIKI_PROJECT = hello-world
all: $(CONTIKI_PROJECT)
CONTIKI = ../..
include $(CONTIKI)/Makefile.include
UPDATE 2: By adding V=1 in the command, my output is:
arm-none-eabi-gcc -march=core2 -mtune=haswell -mssse3 -ftree-vectorize
-fPIC -fPIE -fstack-protector-strong -O2 -pipe -DCONTIKI=1
-DCONTIKI_TARGET_SRF06_CC26XX=1 -DNETSTACK_CONF_WITH_IPV6=1
-DUIP_CONF_IPV6_RPL=1 -DBOARD_SENSORTAG=1 -DBACKDOOR_IOID=0x00000000
-I../../cpu/cc26xx-cc13xx/lib/cc26xxware -I../../cpu/cc26xx-cc13xx
/lib/cc26xxware/driverlib -I../../cpu/cc26xx-cc13xx/lib/cc26xxware/inc
-mcpu=cortex-m3 -mthumb -mlittle-endian -ffunction-sections -fdata-sections
-fshort-enums -fomit-frame-pointer -fno-strict-aliasing -Wall -std=c99 -O2
-I. -I../../platform/srf06-cc26xx/. -I../../platform/srf06-cc26xx
/sensortag/cc2650 -I../../platform/srf06-cc26xx/sensortag -I../../platform
/srf06-cc26xx/common -I../../cpu/cc26xx-cc13xx/. -I../../cpu/cc26xx-cc13xx/dev
-I../../cpu/cc26xx-cc13xx/rf-core -I../../cpu/cc26xx-cc13xx/rf-core/api -I../../cpu/cc26xx-cc13xx/lib/cc26xxware/startup_files -I../..
/cpu/cc26xx-cc13xx/../arm/common/dbg-io -I../../core/dev -I../../core/lib -I../../core/net -I../../core/net/llsec -I../../core/net/mac -I../..
/core/net/rime -I../../core/net/rpl -I../../core/sys -I../../core/cfs
-I../../core/ctk -I../../core/lib/ctk -I../../core/loader -I../../core/. -I../../core/sys -I../../core/dev -I../../core/lib -I../../core/net/ipv6 -I../../core/net/ip -I../../core/net/rpl -I../../cpu/cc26xx-cc13xx
/lib/cc26xxware/driverlib -I../../core/net -I../../core/net/mac -I../..
/core/net/mac/contikimac -I../../core/net/llsec -I../../platform/srf06-
cc26xx/ -I../.. -DCONTIKI_VERSION_STRING=\"Contiki-3.x-3345-g32b5b17\"
-include "contiki-conf.h" -c ../../cpu/cc26xx-cc13xx/lib/cc26xxware
/startup_files/ccfg.c -o obj_srf06-cc26xx/ccfg.o
UPDATE 3: If I do unset CFLAGS, I get a new error message:
/usr/local/Cellar/arm-none-eabi-gcc/9-2019-q4-major/gcc/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: hello-world.elf section `.interp' will not fit in region `FLASH_CCFG'
/usr/local/Cellar/arm-none-eabi-gcc/9-2019-q4-major/gcc/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: region `FLASH_CCFG' overflowed by 9120 bytes
/usr/local/Cellar/arm-none-eabi-gcc/9-2019-q4-major/gcc/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: warning: cannot find entry symbol ad_strip_dylibs; defaulting to 0000000000000000
collect2: error: ld returned 1 exit status
make: *** [hello-world.elf] Error 1
rm obj_srf06-cc26xx/startup_gcc.o hello-world.co obj_srf06-cc26xx/fault-handlers.o
Here's a consolidation of #kfx's solution (which worked like a charm):
unset CFLAGS
unset LDFLAGS
make clean
This is because there may be some other flags which you accidentally set previously, so you have to unset them in order for the compilation to work.
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?
I'm trying to use MinGW-W64 instead of MinGW in Codelite. When I compile simple "hello, world" project it's all right. But when I try to link some libraries, I get a strange linker error. Project with exactly same settings compiles by MinGW with any problems. There are build output for both variants:
MinGW GCC 4.8.1
`C:\Windows\system32\cmd.exe /C D:/apps/mingw/bin/mingw32-make.exe -j8 SHELL=cmd.exe -e -f Makefile
"----------Building project:[ code - Debug ]----------"
mingw32-make.exe[1]: Entering directory 'D:/Projects/codelite/code'
codelite-cc D:/apps/mingw/bin/g++.exe -c "D:/Projects/codelite/code/src/main.cpp" -Wfatal-errors -g -O0 -pedantic -W -std=c++11 -Wall -o ./Debug/src_main.cpp.o -I./inc/
D:/apps/mingw/bin/g++.exe -o bin/code #"code.txt" -L./lib/ -lopengl32
mingw32-make.exe[1]: Leaving directory 'D:/Projects/codelite/code'
====0 errors, 0 warnings====`
MinGW-W64 GCC 5.2.0
`C:\Windows\system32\cmd.exe /C D:/apps/mingw-w64/mingw32/bin/mingw32-make.exe -j8 SHELL=cmd.exe -e -f Makefile
"----------Building project:[ code - Debug ]----------"
mingw32-make.exe[1]: Entering directory 'D:/Projects/codelite/code'
codelite-cc D:/apps/mingw-w64/mingw32/bin/g++.exe -c "D:/Projects/codelite/code/src/main.cpp" -Wfatal-errors -g -O0 -pedantic -W -std=c++11 -Wall -o ./Debug/src_main.cpp.o -I./inc/
D:/apps/mingw-w64/mingw32/bin/g++.exe -o bin/code #"code.txt" -L./lib/ -lopengl32
g++.exe: error: #code.txt -L./lib/: No such file or directory
mingw32-make.exe[1]: *** [bin/code] Error 1
code.mk:78: recipe for target 'bin/code' failed
mingw32-make.exe[1]: Leaving directory 'D:/Projects/codelite/code'
mingw32-make.exe: *** [All] Error 2
Makefile:4: recipe for target 'All' failed
====1 errors, 0 warnings====`
This looks like a bug in your toolchain and not in CodeLite.
There is a space between the "#code.text" and -L./lib and for some reason g++ does not see it...
I put my money on the mingw32-make tool. You can tell CodeLite to use the mingw32-make.exe from the 4.8.1 version (which worked): settings->build settings->compilers->[YOUR COMPILER NAME]->Make
Another option is to disable the option that tells CodeLite to generate Makefile that passes the object list via file to the compiler:
Settings->Build Settings->compilers->[YOUR COMPILER NAME]->Advanced tab and uncheck the option: pass object list to the linker via file
Lately i too have found the similar problem. Later i was able to figure out the issue. We just to need to go to the project settings under change makefile generator default to codelite makefile generator i think that will work.
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.