similar to: [LLVMdev] CallGraphSCCPass: symbol not found

Hi Trevor, > I've written a CallGraphSCCPass that compiles successfully, but when I > try to run it with opt, it fails: > > Symbol not found: __ZTIN4llvm16CallGraphSCCPassE $ c++filt _ZTIN4llvm16CallGraphSCCPassE typeinfo for llvm::CallGraphSCCPass LLVM TOT has RTTI turned off as far as I know (not sure about 2.7). Are you making use of RTTI? Ciao, Duncan.

-----Original Message----- From: Trevor Harmon <Trevor.W.Harmon at nasa.gov> Sent: Tuesday, July 13, 2010 4:46 PM To: Duncan Sands <baldrick at free.fr> Cc: llvmdev at cs.uiuc.edu <llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] CallGraphSCCPass: symbol not found > On Jul 12, 2010, at 11:37 PM, Duncan Sands wrote: > > > $ c++filt _ZTIN4llvm16CallGraphSCCPassE >

Hi, Lately LLVM has been adding -fno-rtti to most of the compiler. I have a pass which uses LoopPass and which inherits from FunctionPass and a class of my own. If I compile my code with ENABLE_RTTI=1, I can't dynamically load the shared object since it won't be able to find the symbol for LoopPass's typeinfo. undefined symbol: _ZTIN4llvm8LoopPassE $ c++filt _ZTIN4llvm8LoopPassE

On Jan 28, 2010, at 12:45 PM, Thomas B. Jablin wrote: > Hi, > Lately LLVM has been adding -fno-rtti to most of the compiler. I > have a pass which uses LoopPass and which inherits from FunctionPass > and a class of my own. If I compile my code with ENABLE_RTTI=1, I > can't dynamically load the shared object since it won't be able to > find the symbol for

On 01/29/2010 12:11 AM, Chris Lattner wrote: > On Jan 28, 2010, at 12:45 PM, Thomas B. Jablin wrote: > > >> Hi, >> Lately LLVM has been adding -fno-rtti to most of the compiler. I >> have a pass which uses LoopPass and which inherits from FunctionPass >> and a class of my own. If I compile my code with ENABLE_RTTI=1, I >> can't dynamically load

Hi @llvm, I've already asked the following questions to the clang dev list but got no response. Maybe there is a wider audience at llvmdev and someone here can help me. The question actually boils down to: How can I compile clang with rtti enabled? And this was my original mail (with some points now better explained) to clang: <--BEGIN--> Hi @clang, I'm somewhat puzzled about

Hi Olaf, On Fri, Sep 11, 2009 at 5:24 AM, Olaf Krzikalla <Olaf.Krzikalla at tu-dresden.de> wrote: > Hi @clang, > > I'm somewhat puzzled about using rtti when building clang under gcc (gcc > 4.3.3, linux/ubuntu). > (There is no problem under MSVC since rtti seems to be active there anyway). > The appropriate line 348 in llvm/makefile.rules is commented out meaning >

Hi all, I'm having problems compiling LLVM 3.2 with RTTI enabled. Since my code makes heavy use of the Boost libraries, RTTI is a must. This is the script I use to compile (as root): SRC_ROOT=$PWD OBJ_ROOT=/export/apps/llvm INSTALL_ROOT=/usr/local mkdir -p $OBJ_ROOT cd $OBJ_ROOT $SRC_ROOT/configure --prefix=$INSTALL_ROOT \

We at Tampere University of technology are using LLVM for high-level optimizations in the compiler for our TTA processor toolkit(TCE) We have a llvm backend which creates our own intermediate code, and our own instruction selector after that (as LLVM's machine code cannot represent the actual machine codes of our processors). This makes our llvm backend quite different from the ordinary

Thanks! Yes, we are trying to avoid that situation as much as possible. Is there any compiler/linker/static analyzer option that would point out those problems (in 13 million lines, large part of that being legacy code)? Currently I don't know any better way than runtime logging and asserting. Also, what shall we do we external source libraries (like Teigha from Open Design Alliance), where

On Feb 17, 2010, at 3:15 AM, Heikki Kultala wrote: > LLVM 2.7 is dropping rtti on default build, which is a problem to us. > We are using Boost libraries on many places in our code, and Boost has > some heavy usage of type info tricks, which cannot be compiled without > rtti, so we have to keep rtti on for our code. > > But our code also implements the llvm backend framework

On Sep 30, 2011, at 3:04 PM, Somorjai, Akos wrote: > Thanks! Yes, we are trying to avoid that situation as much as possible. > > Is there any compiler/linker/static analyzer option that would point out those problems (in 13 million lines, large part of that being legacy code)? There's a -Wweak-vtables which will point out a lot of these cases. I have to warn you that in previous

Thanks, John. I'll experiment with both the warning and the nm-weak external tool, and let you know the results. Best, Akos From: John McCall <rjmccall at apple.com<mailto:rjmccall at apple.com>> Date: Fri, 30 Sep 2011 15:24:33 -0700 To: Ákos Somorjai <asomorjai at graphisoft.com<mailto:asomorjai at graphisoft.com>> Cc: "llvmdev at cs.uiuc.edu<mailto:llvmdev

> Looks like your shared library is not being compiled with symbols. > Did you verify that your sources are compiled with -g? I think so, this is the makefile (based on the one in the Hello pass): > LEVEL = ../../.. > LIBRARYNAME = CGF > LOADABLE_MODULE = 1 > USEDLIBS = > > ifneq ($(REQUIRES_RTTI), 1) > ifneq ($(REQUIRES_EH), 1) > EXPORTED_SYMBOL_FILE =

On 02/17/2010 09:58 PM, Chris Lattner wrote: > You should be able to get this by doing "make REQUIRES_RTTI=1" when building LLVM. What is the main reason RTTI is now disabled by default? We discussed this briefly in IRC but could not reach a proper conclusion and I was directed to ask here for the proper reason against it. Having RTTI support in should not have execution speed

Dear folks, I am trying to handle function pointers at call graph, and I found that the CallGraphSCCPass makes function pointers as external node, which is actually an empty CallGraphNode (NULL pointer)? If I want to distinguish the function pointer types in the call graph (and I also want the SCC order in CallGraphSCCPass), can I do that easily? Or I have to inheritate the

Hi, I'm trying to use CallGraphSCCPass, but I keep getting a bus error. I can reproduce the problem quite easily using the lib/Transforms/Hello example. I simply mix in these changes: #include "llvm/CallGraphSCCPass.h" ... struct Hello : public CallGraphSCCPass { static char ID; // Pass identification, replacement for typeid Hello() : CallGraphSCCPass(&ID) {}

Hi, I am writing a CallGraphSCCPass that uses LoopInfo which is a FunctionPass. However, doing so results in the following error. **** Unable to schedule 'Natural Loop Information' required by '......' **** Google led me to this page, where Devang Patel suggests implementing the addLowerLevelRequiredPasses in CGPassManager in a manner similar to MPPassManager.

I've actually tried to compile both LLVM and my lib with -frtti with same results. On Dec 10, 2012, at 21:57, Jim Grosbach <grosbach at apple.com> wrote: > Llvm typically doesn't build with RTTI enabled. Perhaps that's what you're running into? > > Jim -- Vladimir Pouzanov http://www.farcaller.net/ -------------- next part -------------- A non-text attachment

Hi, I'm trying to use the Java front-end (which, based on svn commits, appears to be three-years-dead), and I'm running into some build errors. In that time did llvm change from building with exception handling and rtti to building without? I remember reading somewhere that llvm code should use dyn_cast instead of dynamic_cast. Do these need to be changed here? A little background: