# Assertion: jl\_TargetMachine
**URL:** https://discourse.julialang.org/t/assertion-jl-targetmachine/26483
**Category:** General Usage
**Created:** [July 17, 2019, 10:44pm UTC](https://discourse.julialang.org/t/assertion-jl-targetmachine/26483 "2019-07-17T22:44:41Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@Orbots](https://discourse.julialang.org/u/Orbots)
#### Post date: [July 17, 2019, 10:44pm UTC](https://discourse.julialang.org/t/assertion-jl-targetmachine/26483/1 "2019-07-17T22:44:42Z")
Summary of situation:
built julia-1.2.0-rc2 from source for centos6 with gcc 6.4.0 and -DGLIBCXX\_USE\_CXX11\_ABI=0
dlopen an .so which embeds some simple julia code. “Lifted” into global namespace with dlopen(RTLD\_NOW | RTLD\_GLOBAL)
from a maya plugin.
jl\_init() results in this assert:
void\* jl\_init\_llvm(): Assertion `jl\_TargetMachine && “Failed to select target machine -” " Is the LLVM backend for this CPU enabled?"’ failed.
Any ideas? A toy julia embedding works fine ( not loaded from maya )
---
### Author:  [@c42f](https://discourse.julialang.org/u/c42f)
#### Post date: [July 18, 2019, 3:05am UTC](https://discourse.julialang.org/t/assertion-jl-targetmachine/26483/2 "2019-07-18T03:05:01Z")
I don’t know why this happens, but since you’re building from source you can investigate by logging out relevant-looking information at the location of the assert:
[https://github.com/JuliaLang/julia/blob/master/src/codegen.cpp#L7718](https://github.com/JuliaLang/julia/blob/master/src/codegen.cpp#L7718)
Also I’d try without RTLD\_GLOBAL; there’s some WIP docs for this at [https://github.com/JuliaLang/julia/pull/28886](https://github.com/JuliaLang/julia/pull/28886)
XRef [embedding julia in .so assert: jl\_TargetMachine · Issue #32616 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/32616)
---
### Author:  [@Orbots](https://discourse.julialang.org/u/Orbots)
#### Post date: [July 18, 2019, 5:17pm UTC](https://discourse.julialang.org/t/assertion-jl-targetmachine/26483/3 "2019-07-18T17:17:51Z")
I had stepped into that function before ( built in debug ) basically most of the parameters to that function are empty. I can do it again, but the assert seems to indicate I’ll see the same thing.
RTLD\_GLOBAL is needed. I’m a little fuzzy on the details of dlopen and namespacing when it relates to shared library symbols. What I believe happens is that maya loads plugins dynamically into a non-GLOBAL namespace ( I can’t control this ). If I then dlopen libjulia into non-GLOBAL namespace ( default in linux, not in other os’s ) and then julia dlopens, for example, sys.so, libjulia does not have access to the symbols from sys.
I might try to change the julia source so it’s dlopen flags default to RTLD\_GLOBAL and see if that works.
---
### Author:  [@Orbots](https://discourse.julialang.org/u/Orbots)
#### Post date: [July 18, 2019, 6:27pm UTC](https://discourse.julialang.org/t/assertion-jl-targetmachine/26483/4 "2019-07-18T18:27:13Z")
RTLD\_GLOBAL vs RTLD\_LOCAL
from the dlopen man pages ( Linux ):
**RTLD\_GLOBAL**
The symbols defined by this library will be made available for symbol resolution of subsequently loaded libraries.
**RTLD\_LOCAL**
This is the converse of **RTLD\_GLOBAL** , and the default if neither flag is specified. Symbols defined in this library are not made available to resolve references in subsequently loaded libraries.
…
If _filename_ is a NULL pointer, then the returned handle is for the main program. When given to **dlsym** (), this handle causes a search for a symbol in the main program, followed by all shared libraries loaded at program startup, and then all shared libraries loaded by **dlopen** () with the flag **RTLD\_GLOBAL**.
External references in the library are resolved using the libraries in that library’s dependency list and any other libraries previously opened with the **RTLD\_GLOBAL** flag. If the executable was linked with the flag “-rdynamic” (or, synonymously, “–export-dynamic”), then the global symbols in the executable will also be used to resolve references in a dynamically loaded library.
* * *
Julia defaults to dlopen(RTLD\_LOCAL) on linux. So anything Julia dlopens: the symbols defined by that library will not be made available for symbol resolution of subsequently loaded libraries. This seems ok.
If libjulia.so was dlopened with RTLD\_LOCAL then it’s symbols won’t be available to anything it dlopens. Not clear what flags the dynamic linker will open libjulia’s dependencies with. This seems to create a problem.
For example, if you build a custom system image, it won’t be able to call any functions in libjulia, which seems a bit crippling. My example here is assuming sys.so ( or whatever your system image is called ) is dlopen by libjulia, which was the case in 0.6, but may not be true now, I haven’t stepped/grepped though the code to confirm it’s still doing so.
---
### Author:  [@Orbots](https://discourse.julialang.org/u/Orbots)
#### Post date: [July 23, 2019, 1:24am UTC](https://discourse.julialang.org/t/assertion-jl-targetmachine/26483/5 "2019-07-23T01:24:03Z")
updated the issue at
XRef [https://github.com/JuliaLang/julia/issues/32616](https://github.com/JuliaLang/julia/issues/32616)
with a MWE in case anyone with more knowledge about dynamic linking cares to take a look.