Hello,

I have compiled a GCC plugin successfully, but I get error when linking:

$ make
/opt/imo/bin/g++ -g -fplugin=../libimo/libimo.so -o test main.cpp
cc1plus: error: Cannot load plugin ../libimo/libimo.so
../libimo/libimo.so: undefined symbol: _ZN11NodeFactory10CreateNodeEN4BEEV4KindERKNS0_7ASTNodeES4_RKSt6vectorIS2_SaIS2_EE
make: *** [default] Error 1

I know that the plugin works fine for other Ubuntu users, so I don't understand what could be the cause of this error on my system. I read on the Internet that "undefined symbol" error means that the linker can not find the line where a specific object was defined in the code.
Is there a way to trace down where the error starts from? Something like a logfile or a backtrace for linker errors?

Thanks!

Dani AI

Generated

Short answer: the plugin loader (cc1plus at runtime) is failing to resolve a C++ symbol from the shared object — this is a dynamic loader problem, not a compile-time/linker mystery. was right to point at a missing definition, and 's sanity-check about the file location is a good first step.

Practical steps to trace the problem (run from the directory with your libimo.so):

nm -D libimo.so | c++filt | grep NodeFactory
readelf -Ws libimo.so | c++filt | grep NodeFactory
objdump -T libimo.so | c++filt | sed -n '1,200p'
ldd libimo.so
readelf -d libimo.so

What to look for: an U entry from nm means the symbol is undefined in libimo.so (it expects resolution from some other shared object or the host). ldd / readelf -d show what libraries libimo.so needs at load time. Use c++filt to demangle symbols so you can match signatures.

Common causes and fixes

  • Missing dependency: the library that actually defines NodeFactory wasn't linked into libimo.so or isn't on the runtime loader path. Add the needed -l or the full .so to the link line (or install it where the loader can find it) so libimo.so has a DT_NEEDED entry.
  • Unresolved-at-build-time allowed: force detection early by linking the plugin with -Wl,-z,defs (or --no-undefined) so the linker fails if symbols remain unresolved.
  • ABI/mangling mismatch: the symbol may exist but with a different mangled name (different compiler flags, headers, namespace or template instantiation). Rebuild the plugin with the exact compiler/version/flags used by the compiler that will load it.
  • Loader diagnostics: run the compiler with LD_DEBUG=libs (or use strace -f -e open) to see which .so load fails and where the loader is searching.

Tiebacks: already showed the binary matched the name — use the nm/readelf checks above to see whether that match is a defined symbol or an unresolved reference, then either link the defining library into libimo.so or rebuild against the correct ABI.

Recommended Answers

All 4 Replies

It says:

Cannot load plugin ../libimo/

. So is the file in that directory?

.so is the usual extension type of plugins (at least in this case):
<plugin_>

The folder where the plugin is located is also correct.

Any clue of how to trace back a linker error?

I don't know of any tools but it seems from the error that it cannot find the definition of some function called NodeFactory::CreateNode . Can you think of any reason why that could be?

NodeFactory does not exist anywhere in the C++ code of the plugin, it is only used after the plugin is built (in the actual <plugin.so> file):

libimo$ grep NodeFactory *.*
Binary file libimo.so matches

I have also no problems to build the plugin - the error above appears when I try to link / test the plugin on some input file. The error is always identical, regardless of the input file.
I also could not find any tools for linker errors online. Maybe it is possible to create something like a build log file that shows the steps of building/linking the plugin. Anyone know how to do that?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.