WolfgangMehner
C-Support: Libraries specified in g:C_Libs not being linked
Hey,
No matter what I do, I can't seem to get the libraries I specify to be linked in when compiling using \rc.
Here's the settings I've set the variables to in my vimrc:
" c.vim settings
let g:C_CCompiler='clang'
" strict compiler settings
let g:C_CFlags='-Weverything -Wno-unused-parameter -std=c99 -g -O0 -v'
" libraries
let g:C_Libs='-lcs50 -lm'
Despite specifying the libraries I want in g:C_Libs, it doesn't show up in the command output, and the build fails at the mention of a function in libcs50:
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
Target: i386-unknown-freebsd10.0
Thread model: posix
"/usr/bin/clang" -cc1 -triple i386-unknown-freebsd10.0 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name calcdumb2.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu i486 -v -g -resource-dir /usr/bin/../lib/clang/3.3 -c-isystem /usr/local/include/ -c-isystem . -O0 -Weverything -Wno-unused-parameter -std=c99 -fdebug-compilation-dir /home/matt/MyProjects/Challenges/Mine -ferror-limit 19 -fmessage-length 0 -mstackrealign -fobjc-runtime=gnustep -fobjc-default-synthesize-properties -fdiagnostics-show-option -backend-option -vectorize-loops -o /tmp/calcdumb2-oheZiR.o -x c /usr/home/matt/MyProjects/Challenges/Mine/calcdumb2.c
clang -cc1 version 3.3 based upon LLVM 3.3 default target i386-unknown-freebsd10.0
ignoring nonexistent directory "/usr/bin/../lib/clang/3.3/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
.
/usr/include/clang/3.3
/usr/include
End of search list.
"/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -m elf_i386_fbsd -o /usr/home/matt/MyProjects/Challenges/Mine/calcdumb2.o /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/calcdumb2-oheZiR.o -L/usr/local/lib -L. -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o
/tmp/calcdumb2-oheZiR.o: In function `main':
/usr/home/matt/MyProjects/Challenges/Mine/calcdumb2.c:29: undefined reference to `GetInt'
/usr/home/matt/MyProjects/Challenges/Mine/calcdumb2.c:31: undefined reference to `GetInt'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Press ENTER or type command to continue
If I made a misconfiguration somewhere along the line, I can't see where it is. This also occurs with gcc.
Compiling the program with a manually crafted clang string works fine, such as:
clang -Weverything -Wno-unused-parameter -std=c99 calcdumb2.c -lcs50 -lm -o calcdumb2.o
I feel bad making a post when I'm a noob and the fault could be from me, but as far as I can tell, it's a bug, as there's no reason I can see for c.vim to not specify the libraries. What's going on here?
Thanks, Matt
Just so we do not miss anything, here comes some probing:
While you're in the buffer with the source code you are trying to compile, what is the output (on the Vim command-line) of:
:echo &filetype
If you use the menu entry " C/C++ -> Run -> settings ", what does this line say:
C file extension : ????? (everything else is C++)
What happens if you use the variable "g:C_CplusLibs" instead?
Hey Wolfgang, thanks for responding so quickly!
The filetype is c. It's displayed on my Vim status bar, but I manually checked as well.
I don't have the GUI, but I presume you're referring to the C_CExtensions variable? How can I check that in text mode?
I just tried C_CplusLibs, and it doesn't appear to affect anything.
I don't have the GUI, but I presume you're referring to the C_CExtensions variable? How can I check that in text mode?
Use the map \rs (or whatever your mapleader is), while in a C/C++ buffer.
It all appears to be right (sorry about all the ASCII vomit)
���������C / C++ compiler : clang / g++
���������C file extension : "c" (everything else is C++)
extension for objects : ".o"
extension for executables : ""
�������compiler flags (C) : "-Weverything -Wno-unused-parameter -std=c99 -g -O0 -v"
���������linker flags (C) : "-Wall -g -O0"
������������libraries (C) : "-lcs50 -lm"
compiler flags (C++) : "-Wall -g -O0 -c"
�������linker flags (C++) : "-Wall -g -O0"
����������libraries (C++) : "-lcs50 -lm"
�����������������debugger : "gdb"
code snippet directory : "/usr/home/matt/dotfiles/dotvim/bundle/c.vim/c-support/codesnippets/"
�����������template style : "C"
plugin installation : "local"
I should've noted: I'm using Vundle for plugin management and getting my copy of c-support from this repo, which I believe is just a github copy of the version from vim-scripts.org. I don't think either of these are causing it, but it's a computer and I'm an idiot, so you can never leave anything out.
Don't worry, computers drive us all insane.
-
You actually have to specify the compiler and linker flags separately. And g:C_CFlags has to cause compilation only (this behavior has to be reviewed). I don't know clang, but maybe:
let g:C_CFlags='-Weverything -Wno-unused-parameter -std=c99 -g -O0 -v -c' let g:C_LFlags='-Weverything -Wno-unused-parameter -std=c99 -g -O0 -v'
-
Maybe a second test after that failed (but fingers crossed). I wonder whether the order of the arguments matters. Try and include the libraries in the flag variables for the moment:
let g:C_CFlags='-Weverything -Wno-unused-parameter -std=c99 -g -O0 -v -lcs50 -lm -c' let g:C_LFlags='-Weverything -Wno-unused-parameter -std=c99 -g -O0 -v -lcs50 -lm'
WOO! #1 worked! :D
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
Target: i386-unknown-freebsd10.0
Thread model: posix
"/usr/bin/clang" -cc1 -triple i386-unknown-freebsd10.0 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name calcdumb2.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu i486 -v -g -coverage-file /usr/home/matt/MyProjects/Challenges/Mine/calcdumb2.o -resource-dir /usr/bin/../lib/clang/3.3 -c-isystem /usr/local/include/ -c-isystem . -O0 -Weverything -Wno-unused-parameter -std=c99 -fdebug-compilation-dir /home/matt/MyProjects/Challenges/Mine -ferror-limit 19 -fmessage-length 0 -mstackrealign -fobjc-runtime=gnustep -fobjc-default-synthesize-properties -fdiagnostics-show-option -backend-option -vectorize-loops -o /usr/home/matt/MyProjects/Challenges/Mine/calcdumb2.o -x c /usr/home/matt/MyProjects/Challenges/Mine/calcdumb2.c
clang -cc1 version 3.3 based upon LLVM 3.3 default target i386-unknown-freebsd10.0
ignoring nonexistent directory "/usr/bin/../lib/clang/3.3/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
.
/usr/include/clang/3.3
/usr/include
End of search list.
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
Target: i386-unknown-freebsd10.0
Thread model: posix
"/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -m elf_i386_fbsd -o /usr/home/matt/MyProjects/Challenges/Mine/calcdumb2 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /usr/home/matt/MyProjects/Challenges/Mine/calcdumb2.o -lcs50 -lm -L/usr/local/lib -L. -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o
If I can make a guess, I think the problem must've been the lack of the -c flag. I didn't know that the program did linking as a separate step from the compilation, so I removed it -- though, if I remember correctly, I may have been having linking problems with the c flag still present. I'll check...
EDIT: Yep, removing -c causes compilation to fail. That seems like a pretty easy thing to stumble upon, so I think I'll add that to the troubleshooting section of the docs so you can incorporate it it you like.
Do a fork and I either pull it or I commit your patch, which I can also get from the pull request. Should not appear in the troubleshooting section though, a proper description of the behavior in the appropriate sections of the documentations would be nicer. But I can also do that myself, I do not think it will be a lot of work.