Undefined reference to `getEmbeddedConstPool'

Beginners
#1

I converted ONNX to MLIR using onnx-mlir --EmitMLIR.
I added main function to pass input to graph and print statement to print the output of graph.
Then I lowered LLVM Dialect using onnx-mlir-opt --convert-krnl-to-llvm and.onnx.mlir>n1.mlir.
Lowered to LLVM IR using mlir-translate --mlir-to-llvmir n1.mlir>n2.ll
the I ran the .ll file using clang n2.ll “pathto”/libmlir_runner_utils.so -o main -lm
/usr/bin/ld: /tmp/n2-dacb78.o: in function main_graph': undefined reference to getEmbeddedConstPool’
/usr/bin/ld: /tmp/n2-dacb78.o: in function _dyn_entry_point_main_graph': undefined reference to getRtMemRef’
undefined reference to getData' undefined reference to getSizes’
undefined reference to getStrides' undefined reference to createOrderedRtMemRefDict’
undefined reference to createRtMemRef' undefined reference to setData’
undefined reference to setDType' undefined reference to getSizes’
undefined reference to getStrides' undefined reference to setRtMemRef’

I am getting error like above.
How can I solve this?

#2

I made Linux From Scratch GNU/Linux x-lfs-2010 - Browse Files at SourceForge.net

  1. somehow some.o were not made, the build did not stop (that would be unusual).

  2. some “ifdef FOO” excluded cerain functions that are in LLVM from getting in the .o (this happens in “often hacked” software like GLIBC but i think not LLVM)

ANSWER: likely your build tools are not of the minimum version or perhaps TOO NEW. the llvm build scripts rely on them.

I’ve dealt with thousands of build fails. If you get that it means: use “objdump -axSD libfoo.[s]o”, you’ll see those are listed not as .Text but UND

objdump -axSD file.o | less -S # confirm erro message cd llvm-…-build/
$ grep -r createOrderedRtMemRefDict . | less -S

you now see where the definitions are. they must be in LLVM since n2-dacb78.o is a .o not a .so (linking to other shared libs can’t be the issue, if it were a a.out or foo.so you might get messages if linker did not include “NEED someother.so” in the .so, but for .o that’s never an issue)

Now your face with: either
#ifdef MY_MACH foo() #endif left you without fun defined OR

… you have a compiler toolchain problem. llvm’s scripts are working but your tool chain is not

THE FIRST THING YOU DO IS CHECK BUILD OPTIONS, rtfm, make sure. Read the build instructions and advices twice. run ./configure --help and supply the same options you would when compiling any GNU autonfig project (if you don’t know that, see xlfs-2010, or LFS linux from scratch, or google it).

THE TOP build option i would say to check is: first that you have required versions of
gcc, g++, libtool, and whatever else LLVM says to check are minimum.

[ -n “$std” ] && CFLAGS="$CFLAGS -std=$std "
[ -n “$std” ] && CPPFLAGS="$CPPFLAGS -std=$std "
[ -n “$stdpp” ] && CXXFLAGS="$CXXFLAGS -std=$stdpp"

don’t use -std=gnu89 or what, llvm is c++ code and doesn’t like it

do use stdpp=gnu++11 or the build will go crazy

#3

this is xlf’s “list of standard gnu build options”

one of them, --enable-shared needs to be revised as “–enabled-shared=yes”

–build
–prefix
–exec-prefix
–with-tls
–with-gnu-ld
–with-shared
–enable-shared
–enable-big-core
–with-libtool
–enable-threads
–with-threads
–with-pthread
#for_cairo
–enable-pthread
–enable-termcap
#–with-curses
–disable-profile
–disable-dependency-tracking
–disable-nls
–disable-rpath
–enable-rpath
–disable-acl
–disable-rpath
–disable-gold
–disable-cloog
–disable-ppl
–disable-libssp
–disable-libcap
–disable-libmudflap
–disable-xattr
–disable-selinux

not a mistake

–without-xmlto
–with-xmlto
–disable-build-docs
–with-x