After completing all installation steps for the CommandT plugin, I get the error command-t.vim could not load the C extension when starting it. The ComamndT troubleshooting section gives this advice:
If a problem occurs the first thing you should do is inspect the output of:
ruby extconf.rb
make
During the installation, and:
vim --version
And compare the compilation and linker flags that were passed to the
extension and to Vim itself when they were built. If the Ruby-related
flags or architecture flags are different then it is likely that something
has changed in your Ruby environment and the extension may not work until
you eliminate the discrepancy.
And it does indeed seem that there is discrepancy for me.
Output from make suggests cygwin's gcc is using ruby 1.8:
gcc -I. -I/usr/lib/ruby/1.8/i386-cygwin -I/usr/lib/ruby/1.8/i386-cygwin -I. -DHA
VE_RUBY_H -g -O2 -std=c99 -Wall -Wextra -Wno-unused-parameter -c ext.c
gcc -I. -I/usr/lib/ruby/1.8/i386-cygwin -I/usr/lib/ruby/1.8/i386-cygwin -I. -DHA
VE_RUBY_H -g -O2 -std=c99 -Wall -Wextra -Wno-unused-parameter -c match.c
gcc -I. -I/usr/lib/ruby/1.8/i386-cygwin -I/usr/lib/ruby/1.8/i386-cygwin -I. -DHA
VE_RUBY_H -g -O2 -std=c99 -Wall -Wextra -Wno-unused-parameter -c matcher.c
gcc -shared -s -o ext.so ext.o match.o matcher.o -L. -L/usr/lib -L. -Wl,--enabl
e-auto-image-base,--enable-auto-import,--export-all -lruby -ldl -lcrypt
Output from vim's :version contains this output:
-DDYNAMIC_RUBY_VER=191 -DDYNAMIC_RUBY_DLL=\"msvcrt-ruby191.dll\"
The troubleshooting guide suggests using a combination of Vim 7.2, Ruby 1.8.7-p299, and DevKit 3.4.5r3-20091110. However this is not a good solution for me for a number of reasons:
I'm using Vim 7.3 and would like to continue doing so.
Ruby 1.9.3 is installed on my system, and I need it in my PATH for other projects.
So is there any way to get this working, while keeping the latest version of ruby and the latest version of vim?
UPDATE
Having followed AndrewMarshall's advice, I installed Ruby191 and DevKit-4.5.0-20100819-1536-sfx.exe according to this tutorial and ran ruby extconf.rb through that version. The make cmd executed successfully with this output:
gcc -I. -IC:/Ruby191/include/ruby-1.9.1/i386-mingw32 -I/C/Ruby191/include/ruby-1
.9.1/ruby/backward -I/C/Ruby191/include/ruby-1.9.1 -I. -DHAVE_RUBY_H -O2 -g -
Wall -Wno-parentheses -std=c99 -Wall -Wextra -Wno-unused-parameter -o ext.o -c
ext.c
gcc -I. -IC:/Ruby191/include/ruby-1.9.1/i386-mingw32 -I/C/Ruby191/include/ruby-1
.9.1/ruby/backward -I/C/Ruby191/include/ruby-1.9.1 -I. -DHAVE_RUBY_H -O2 -g -
Wall -Wno-parentheses -std=c99 -Wall -Wextra -Wno-unused-parameter -o match.o
-c match.c
gcc -I. -IC:/Ruby191/include/ruby-1.9.1/i386-mingw32 -I/C/Ruby191/include/ruby-1
.9.1/ruby/backward -I/C/Ruby191/include/ruby-1.9.1 -I. -DHAVE_RUBY_H -O2 -g -
Wall -Wno-parentheses -std=c99 -Wall -Wextra -Wno-unused-parameter -o matcher.
o -c matcher.c
gcc -shared -s -o ext.so ext.o match.o matcher.o -L. -LC:/Ruby191/lib -L. -Wl,-
-enable-auto-image-base,--enable-auto-import -lmsvcrt-ruby191 -lshell32 -lws2
_32
and running :CommandT in vim works now, but as soon as I start typing to search for a file, and then hit enter to select and open it, I get this:
not a real answer but you may wanna try ctrlp instead.
written in vimscript (no dependency, no compiling)
as fast as CommandT (subjective to me)
has probably more features than CommandT (does CommandT have most recent file?)
there is also the good old FuzzyFinder which I haven't tried. seems like it hasn't got updated for about 2 years but it may still be working.
I successfully installed newest command-t on vim 8.0 on windows 10. And I find this question when I'm working on it so I'm gonna post my solution although it's a little late.
Ruby version for vim 8.0 is Ruby 2.2. So download and install Ruby 2.2 and Ruby Devkit (remember to execute ruby dk.rb init and ruby dk.rb install for devkit ).
Then I follow the command-t instruction to execute ruby extconf.conf, but it failed -- it output You have to install development tools first. even though I did install it:
I googled this issue find RubyInstaller wiki says that I should execute this command by add -rdevkit and I did it. It succeed when I execute ruby -rdevkit extconf.rb but failed when make. So I googled again and find another way to compile it:
rake make -rdevkit
And it worked. Here is my screenshot:
Related
I have a mid size cross-platform application that I can start debugging in 2 to 3 seconds from click "Start Debugging" to hitting a breakpoint at the top of the main() method. This is when built with MSVC2019 toolset in Visual Studio.
The same application is also compiled under Ubuntu 20.04 and MacOS using clang-10 and debugged with LLDB. However, either in VSCode or Qt Creator it takes about 15 seconds from click "Start debugging" to hitting the same breakpoint. It looks like the majority of the time is spent loading symbols from the shared objects. On MacOS, despite being developed with a MacBook and not having a powerful desktop CPU, it loads in about 6 seconds, i.e. faster.
Compiler args being used:
clang -x c++ -std=c++17 -O0 -g -fPIC -fmessage-length=0 -fstrict-aliasing -stdlib=libc++ -isystem "/usr/lib/llvm-10/include/c++/v1/" -isystem "/usr/include" -MMD -MF $out.d -o $out -c $in
Linker args being used:
clang -O0 -fPIC -fmessage-length=0 -fstrict-aliasing -stdlib=libc++ -g -fvisibility=hidden -pedantic-errors -fobjc-arc -z noexecstack -z relro -z now -lc++ -lc++abi -lm -lrt -shared -Wl,-rpath,'$$ORIGIN',-z,origin -o $out #$out.rsp
My question is, is there a well known combination of clang compiler/linker flags or lldb settings that can be tweaked to improve debugger startup time when developing on Linux?
I've tried settings set target.preload-symbols false on lldb init commands, but it didn't help much.
I have 2 versions of SDK for Qt Creator: Compiled from Open Source and Compiled from bitbake.
The Open Source SDK is working fine, but the bitbake one is having trouble recognizing the compiler. I have added the g++ compiler to build & Run and source environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabias well.
make: c: Command not found make: [moc_utils.o] Error 127 (ignored)
make:
Wl,-rpath-link,/opt/poky/charles/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib:
Command not found make: [quicknanobrowser] Error 127 (ignored)
Here is the error one Compiler Log:
14:27:55: Running steps for project quicknanobrowser...
14:27:55:
Starting:
"/opt/poky/charles/sysroots/x86_64-pokysdk-linux/usr/bin/qt5/qmake"
/home/hbulab/Qt5.5.1/Examples/Qt-5.5/webengine/quicknanobrowser/quicknanobrowser.pro
-r -spec linux-oe-g++ CONFIG+=debug CONFIG+=declarative_debug CONFIG+=qml_debug
14:27:55: The process
"/opt/poky/charles/sysroots/x86_64-pokysdk-linux/usr/bin/qt5/qmake"
exited normally.
14:27:55: Starting: "/usr/bin/make"
c -pipe -g
-DLINUX=1 -DEGL_API_FB=1 -Wall -W -D_REENTRANT -fPIC -DQT_QML_DEBUG -DQT_DECLARATIVE_DEBUG -DQT_WEBENGINE_LIB -DQT_QUICK_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I.
and here is the one without error, we could see that the make could not find the g++ compiler. How do I fix it?
14:29:08: Running steps for project quicknanobrowser... 14:29:08:
Starting: "/opt/hio-imx6dl-board/opt/Qt5daisy/bin/qmake"
/home/hbulab/Qt5.5.1/Examples/Qt-5.5/webengine/quicknanobrowser/quicknanobrowser.pro
-r -spec devices/linux-imx6-g++ CONFIG+=debug CONFIG+=declarative_debug CONFIG+=qml_debug
14:29:09: The process
"/opt/hio-imx6dl-board/opt/Qt5daisy/bin/qmake" exited normally.
14:29:09: Starting: "/usr/bin/make"
/opt/poky/1.6.1/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++
-c -pipe -march=armv7-a -mfpu=neon -DLINUX=1 -DEGL_API_FB=1 -mfloat-abi=hard -g -Wall -W -D_REENTRANT -fPIC -DQT_QML_DEBUG -DQT_DECLARATIVE_DEBUG -DQT_WEBENGINE_LIB -DQT_QUICK_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I.
MakeFile Information:
MAKEFILE = Makefile
####### Compiler, tools and options
CC = $(OE_QMAKE_CC)
CXX = $(OE_QMAKE_CXX)
DEFINES = -DQT_QML_DEBUG -DQT_DECLARATIVE_DEBUG -DQT_WEBENGINE_LIB -DQT_QUICK_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB
CFLAGS = -pipe $(OE_QMAKE_CFLAGS) -g -DLINUX=1 -DEGL_API_FB=1 -Wall -W -D_REENTRANT -fPIC $(DEFINES)
CXXFLAGS = -pipe $(OE_QMAKE_CXXFLAGS) -g -DLINUX=1 -DEGL_API_FB=1 -Wall -W -D_REENTRANT -fPIC $(DEFINES)
INCPATH = -I../../../Qt5.5.1/Examples/Qt-5.5/webengine/quicknanobrowser -I. -isystem /opt/poky/charles/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/include/qt5 -isystem /opt/poky/charles/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/include/qt5/QtWebEngine -isystem /opt/poky/charles/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/include/qt5/QtQuick -isystem /opt/poky/charles/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/include/qt5/QtWidgets -isystem /opt/poky/charles/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/include/qt5/QtGui -isystem /opt/poky/charles/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/include/qt5/QtQml -isystem /opt/poky/charles/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/include/qt5/QtNetwork -isystem /opt/poky/charles/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/include/qt5/QtCore -I. -I/opt/poky/charles/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/qt5/mkspecs/linux-oe-g++
QMAKE = /opt/poky/charles/sysroots/x86_64-pokysdk-linux/usr/bin/qt5/qmake
As ${OE_QMAKE_CXX} is empty, that indicates to me that you haven't source environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabiasenvironment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi.
This should work to compile by hand:
. /opt/poky/charles/environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi
echo $OE_QMAKE_CXX
qmake
make
(Assuming you don't need to pass any extra arguments to qmake).
Then do the following:
. /opt/poky/charles/environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi
echo $OE_QMAKE_CXX
qtcreator
Note that you should start qtcreator from the same shell that you source environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi in.
This should get you going. Otherwise I'd suggest starting by getting a small, simple Qt appliction building correctly.
For more in configuring QtCreator, you could for instance have a look at how to setup QtCreator for cross-compilation.
Update
As it seems that Qt5 isn't included in the SDK at all, we first have to generate a suitable SDK. My preferred way:
bitbake your-image -c populate_sdk
This works, as long as your image recipe includes
inherit populate_sdk_qt5
That would give you an SDK, whose sysroot would match your image.
The "older" way, is to use a special toolchain recipe. For Qt5 that would be meta-toolchain-qt5, or some recipe that includes/requires that one. In this case, you would run:
bitbake meta-toolchain-qt5
Though, the recommended way is to use the image specific SDK.
I facing some trouble compiling my programming assignment on my local machine. The program is distribute to us with makefiles and compilation commands that are known to work on the school's Scientific Linux servers. My local machine is Mac OS X El Capitan.
When I compile my program running make on my Mac, I get the following error that prevents compilation from proceeding:
myid-MacBook-Pro:mp6 myid$ make
gcc -g -lm -std=c99 -Wall -Werror -c lodepng.c
clang: error: -lm: 'linker' input unused
make: *** [lodepng.o] Error 1
But when I push that very same code as work in progress to the Linux servers and compile there, everything works fine. The linux servers use gcc and not clang:
[netid#linux-a2 mp6]$ make
gcc -g -lm -std=c99 -Wall -Werror -c functions.c
gcc -g -lm -std=c99 -Wall -Werror main.o lodepng.o imageData.o functions.o -o mp6 -lm
gcc -g -lm -std=c99 -Wall -Werror -c test.c
gcc -g -lm -std=c99 -Wall -Werror test.o lodepng.o imageData.o functions.o solution.o -o test -lm
In the makefile, these are the variable definitions:
CC=gcc
CFLAGS=-g -lm -std=c99 -Wall -Werror
and the target definition for loadpng.o
lodepng.o: lodepng.c
$(CC) $(CFLAGS) -c lodepng.c
I would appreciate any help on understanding this error and overcoming it.
Thank you very much.
Also, on this note, I thought I would say that I've noticed a subtle difference between Clang and GCC. It seems to me that even warnings generated by Clang would prevent the compilation to proceed so the warnings behaves like errors. But for GCC, if it generates warnings, it still compiles the object file. Please correct me if I'm mistaken.
Right now you're getting a compilation error on your Mac because you're trying to pass linker commands (i.e. -lm) into a compilation(i.e. -c). Do not give link flags when you compile (-c flag) your source files.
In the other compilation snippet you provided, the unused linker command seems to pass by unnoticed which isn't a good thing.
For your last question, the flag -Werror should force all compilation warnings to become errors -- which is exactly what you are describing.
I want to cross compile an application from my workstation (x86, linux) for an ARM application processor. First I build for my system:
gcc -static -g -Wall -c main.c -o main.o
gcc -g -Wall main.o -o myApplication -lncurses
this build like I want and also work. If I want to build this for arm
arm-linux-gnueabi-gcc -static -g -Wall -c main.c -o main.o
arm-linux-gnueabi-gcc -g -Wall main.o -o myApplication -lncurses
But this will not compile.
/usr/lib/gcc-cross/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/bin/ld: cannot find -lncurses
collect2: Error
So: how to cross-compile a ncurses Application in this way?
One easy way to do it would be to download a binary release of ELLCC. It comes with a pre-built libraries, including ncurses. The download page is here. If you grab e.g. http://ellcc.org/releases/ellcc-x86_64-linux-eng-0.1.27.tgz (The version number will change over time), you can untar it. For the ARM, your build lines would look like:
~/ellcc/bin/ecc -target arm-linux-engeabihf -g -Wall -c main.c -o main.o
~/ellcc/bin/ecc -target arm-linux-engeabihf -g -Wall main.o -o myApplication -lncurses
It creates a static binary, so you don't have to worry about shared library versions.
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