Symbol not found in opt when using own pass

Hi everyone,

I have a terrible feeling I'm doing something really silly here, but I can't
seem to solve the problem after a day of trying now. I'm currently writing
my own pass which I am running by loading it into the opt tool. Everything I
had written in the pass so far had worked, until I started declaring an
#include of some extra header files which I had written myself (they are
objects for modeling a graph I am constructing):

#include "VSDGNode.h"
#include "VSDGPlace.h"
#include "VSDGTransition.h"
using namespace vsdg;

In my function for constructing my graph, I declare an object:

   VSDGTransition t;

however, at run-time, the pass fails with the following error:

dyld: lazy symbol binding failed: Symbol not found:
__ZN4vsdg14VSDGTransitionC1Ev
  Referenced from:
/Users/js231/svn-check/js231/code/llvm-2.5/Release/lib/VSDGConstruct.0.0.0.dylib
  Expected in: flat namespace

dyld: Symbol not found: __ZN4vsdg14VSDGTransitionC1Ev
  Referenced from:
/Users/js231/svn-check/js231/code/llvm-2.5/Release/lib/VSDGConstruct.0.0.0.dylib
  Expected in: flat namespace

// Memory dump omitted...

Segmentation fault

Which seems to suggest that in the .dylib file the symbol cannot be found.
However, actually looking at the .dylib file it appears to be in there. Is
there some kind of linking problem with my pass, or is there something very
stupid that I am or am not doing? I can provide any more information if
needed, I just didn't want to make the post unreadable if it was an obvious
answer.

Thanks very much, as ever.

James

James Stanier wrote:

Hi everyone,

I have a terrible feeling I'm doing something really silly here, but I can't
seem to solve the problem after a day of trying now. I'm currently writing
my own pass which I am running by loading it into the opt tool. Everything I
had written in the pass so far had worked, until I started declaring an
#include of some extra header files which I had written myself (they are
objects for modeling a graph I am constructing):

Jamie, I've found that opt doesn't work quite right when using custom loaded modules. If you use the opt in the build bin directory rather than the installed one you shouldn't have this problem, i.e.,

   ~/path/to/build/Release/bin/opt -load whatever

rather than just

   opt -load whatever

I have absolutely no idea what the problem actually is, since the workaround works and I haven't felt the need to track anything down. I usually have a make target and set OPT appropriately.

Hope this works for you,
Luke

James,

Luke Dalessandro wrote:

Jamie,

Sorry about that, I must need more coffee. Hope the fix works.

Unfortunately I'm now at home and not my desk, but I'm already using the opt
tool which resides in the /Release/bin/ directory, so I don't think this is
the case.

The problem seems to explicitly occur when creating objects of header files
that aren't within the llvm or std library. I created a junk header file
called Rubbish.h with minimal content (a private integer and a get/set
method), and when I tried to create an object of that type:

   Rubbish r;

I got the exact same error as previously posted, no matter where in the .cpp
file I wrote it. This makes me think that, somehow, it can't find symbols
for any of my own #include header files, no matter what they happen to be. I
ran this by some people in my lab who couldn't seem to work it out either.

My project lies within /lib/Transforms/VSDGConstruct, next to the Hello
example. All of my .h and .cpp files are in there. Is there some possibility
that the header files should be elsewhere?

I am rather confused...

James

Luke Dalessandro-2 wrote:

Hi,

I fixed my problem and thought I'd follow up as I've seen it pop up a few
times before on the mailing list, and maybe it will be of some use to
somebody else in the future. The problem is a completely silly one.

When writing your own header files for inclusion in a pass, always make sure
that an implementing .cpp file is written. Don't try and be lazy by just
writing all of the functions in the header; the linker won't be able to find
them without .cpp file.

This (stupid) solution was tested on Mac and also Linux.

Best,

James

James Stanier wrote: