I have installed the latest LLVM svn trunk using cmake (this is the first time I have used cmake to build LLVM).
The problem is that when I try to make the Hello pass from the LLVM tutorial, it compiles fine (a .so file is created), but the opt tool is unable to load it. It fails with the following message
$ opt -load ./Hello/libLLVMHello2.so
Error opening './Hello/libLLVMHello2.so': ./Hello/libLLVMHello2.so: undefined symbol: _ZTIN4llvm12FunctionPassE
-load request ignored.
I am using cmake, and following the instructions at http://llvm.org/docs/CMake.html#cmake-out-of-source-pass
I have some other passes lying around, but I do not want to use the cmake build system until this problem is solved.
Any suggestions would be helpful. Thank you!
You built your Hello pass with rtti enabled, while LLVM is built without.
Related
I am working with LLVM 8.0 and clang and am performing some work during the optimization and I need to get the path to clang. I am running clang using the -flto flag, so that clang actually calls the linker and ultimately my code. I am doing this on Ubuntu 16.04.
I'm trying to get the image path using readlink("/proc/self/exe");. The clang image was build in my home folder, so the path I specify to run clang is /home/users/me/llvm/build/llvm/bin/clang. I also have a version of clang installed in /usr/bin/clang.
What I get from the call to readlink is: /usr/bin/ld.
What I want to get is: /home/users/me/llvm/bin/clang.
I realize that -flto calls system() with /usr/bin/ld ... as the command to run. But how can I get the clang path? Since I have multiple versions of clang, I cannot use whereis or the like, as it will return either the wrong one or multiple.
Is there a global variable in LLVM, or some way to query LLVM, or some way I have not yet discovered to get the image path for the parent process?
The suggestions for using getppid and using the in the "?/proc//exe" worked perfectly.
The suggestion by #Ismail was perfect. Did exactly what I wanted it to.
I have a programming language I'm fiddling with and it calls clang to link the bitcode file it emits. (Perhaps there is a better way to do this all together?) I've been using Visual Studio Code to debug it and it has mostly worked great.
I recently upgraded llvm. At that point, builtin osx clang was complaining about not recognizing a bitcode construct. So I installed clang part of llvm with brew. This looks to work for the compiler but fails to call the linker.
When I run a debug session I get this in the debug window:
clang-6.0: error: unable to execute command: Executable \"ld\" doesn't exist!
However, if I run from the embedded terminal it works fine.
It seems like clang is trying to explicitly expand the location of ld rather than using builtin path resolution. Something in VSCode's C++ debugger launched environment is causing issues with it.
Some supporting bits of diagnosis (trying to keep this a bit short for now...).
When run from the debugger:
whereis ld works and emits...
/usr/bin/ld
env emits what looks like a wrapped environment...
PWD=/Users/<snipped>
SHLVL=1
_=/usr/bin/env
echo $PATH emits...
/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.
And clang tries to link it runs "ld" and says...
clang-6.0: error: unable to execute command: Executable "ld" doesn't exist!
When run from the embedded terminal on the other hand:
whereis ld works and emits...
/usr/bin/ld
env emits...
a metric ton of stuff including
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin
echo $PATH emits...
/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.
And clang tries to run "/usr/bin/ld" which works fine.
I realize this may be a clang ld lookup bug (not correctly expanding _=/usr/bin/env??). Unfortunately A) I don't know very much about OSX environment expansion B) if VSCode C++ debugger is using some sort of standard OSX environment jujitsu or not C) not sure how to debug clang run from within an existing VSCode debugger session D) don't know how to emulate the VSCode debugger environment setup to get started unravelling the ball of yarn.
I think I've upgraded OSX/XCode that I'm now unblocked (using the builtin clang compiler from within the VSCode debugger works again). I figured I'd raise this anyway in case I can get a problem fixed or at least learn something.
Any thoughts/suggestions?
Thanks,
Adrian
I installed CLang on CentOS using sudo yum install clang. Then tried using it by firing this command clang++ main.cpp -o main. This complained of missing ld.
Prior to this I had deleted the usr/bin/ld
I read that llvm has it's own linker; I am unable to find one. I also read that llvm lld was removed and the documentation says that one can make do with Clang only. Given that I have removed /usr/bin/ld, how do I get it back? Do I need to get it back? How do I make CLang use the linker that is supposed to be included with Clang?
I am debugging an issue and to one of the steps in trying to fix the issue was to reinstall the compiler, hence I resorted to deleting all the previously installed packaged and files, including ld.
Hi anyone can help with dependency_info.dat No such file or directory? I'm using Xcode 7 with gcc 4.8
-dependency_info /path/my_project/build/my_project/Debug/my_project.build/Objects-normal/x86_64/my_project_dependency_info.dat
g++-4.8: error:/path/my_project/build/my_project/Debug/my_project.build/Objects-normal/x86_64/my_project_dependency_info.dat: No such file or directory
Command /usr/local/bin/g++-4.8 failed with exit code 1
what does -dependency_info flag do? How can I remove this flag?
The error went away after I deleted the path specified in Build Settings "Path to Linker Dependency Info File" for the project and the targets. So far the app is compiling and running fine without a specified path.
I had a very similar error with Xcode 7.2, OpenCV 3 and El Capitan.
In my case (and probably in yours as well), it's a linker error disguised as something else.
My project builds fine via terminal (because it already has a makefile that uses gcc), but no chance with XCode even after I configure everything in Build Settings pane according to the makefile.
This answer saved me. My OpenCV was installed using macports (it might have been precompiled binaries, or compiled on my machine, can't remember). It turns out that it's compiled with libc++ and not libstdc++.
Changing the C++ Standard Library setting accordingly in Build Settings did the trick for me.
For me it was trying to use a "/" in the app's display name that caused the build error
I cannot compile anything with the current version of emscripten from the ubuntu repos
Here is the error
http://pastebin.com/j5Z0ztTs
I suspect it might be because emscripten is outdated in the repos, but why is there no bug reports??
Could anyone help? I cannot find any updated information.
Thanks in advance.
The reason is because you are using the /usr/bin/clang++ that comes with your Linux distribution.
This version does not support Javascript backend. In order to use emscripten, you have to compile fastcomp (an LLVM clang compiler with Javascript backend added)
If you have not built fastcomp yet, Emscripten won't work.
Check out this page for installation instructions:
http://kripken.github.io/emscripten-site/docs/building_from_source/LLVM-Backend.html
If you have already built fastcomp, then the problem is in your emscriptenrc file, and moreover your PATH.
This is how I worked around the issue:
I created a file called emscriptenrc.sh that did this:
export PATH=/home/mike/emscripten/fastcomp/build/master/bin:/home/mike/emscripten/fastcomp/build/master/include:/home/mike/emscripten/fastcomp/build/master/lib:$PATH
then after I created that file
I rebuilt the ~/.emscripten configuration file by calling
./emcc -v from the emscripten build directory -- this seemed to get the right version of clang registered...
now you can go ahead and compile with emcc
I would suggest reading http://kripken.github.io/emscripten-site/docs/building_from_source/LLVM-Backend.html
as well as the rest of the documentation prior to trying to use emscripten.