Have you tried adding the following: -Wl,--export-dynamic
to the linking of the main executable? I think on linux you need that to export symbols from the binary so the dynamic linker can find it (LLVM internally uses dlopen/dlsym to find symbols in the binary). Zach On Wed, Aug 6, 2014 at 8:13 PM, Husselmann, Alwyn < [email protected]> wrote: > Hi all, > > I am linking Terra directly into an app of mine, and loading some luaterra > from a file called config.t. > > In config.t I might call some C functions exposed by my code like this: > > sim = terralib.includecstring([[ > #include "terrafn.cuh" > ]], "-I", ".", "-I", "..", "-I", "./app") > > terra hello() > var l = sim.realtime() > return [uint32](l) > end > hello() > > I get an LLVM ERROR saying that the external realtime() could not be > resolved. > > I have attempted to solve this problem by providing -fPIC to clang++, > which doesn't work. HOWEVER, if I compile my binary by putting everything > in a library and linking to that, it works perfectly fine: > > clang++ -g -shared -o libslab.so ./*.o > clang++ -c -pipe -fpermissive -g -fPIC .................. -I. -o main.o > main.cpp > clang++ -ccc-gcc-name g++ ....... -o mol -L. -lslab > ............................... > > In fact, I've been doing it this way for a long time, ignoring the > problem. Now I would prefer it to be in the same binary, because I don't > really want to hack my Qt .pro file to pieces. > > Also, I do make sure I use the usual extern "C" where appropriate. > > Any tips greatly appreciated. > > Regards, > Alwyn > _______________________________________________ > terralang mailing list > [email protected] > https://mailman.stanford.edu/mailman/listinfo/terralang > >
_______________________________________________ terralang mailing list [email protected] https://mailman.stanford.edu/mailman/listinfo/terralang
