On Sun, Jul 24, 2016 at 1:21 PM, Joosep Pata <[email protected]> wrote: > Hi, > > I'd like to compile ui/repl.c into a shared library so that I could dlopen > julia after some other initialization procedures that would otherwise > conflict with the LLVM linked to julia.
You should **NOT** compile `ui/repl.c` since it will fail as you saw. You should just use `libjulia.so`, why is it not enough? `ui/repl.c` is just a very thin wrapper and should have nothing to do with LLVM or whatever conflict you saw. > > I succeeded in doing that on OSX using: > > ~~~ > diff --git a/ui/Makefile b/ui/Makefile > +julia-release: $(build_bindir)/julia$(EXE) > $(build_private_libdir)/librepl.$(SHLIB_EXT) > ... > +$(build_private_libdir)/librepl.$(SHLIB_EXT): $(OBJS) > + @$(call PRINT_LINK, $(CXXLD) -shared $(CXXFLAGS) $(CXXLDFLAGS) > $(LINK_FLAGS) $(SHIPFLAGS) $^ -o $@ -L$(build_private_libdir) > -L$(build_libdir) -L$(build_shlibdir) > ~~~ > > so I can call julia dynamically as > ~~~ > my_init(); // initalize stuff that hides its LLVM symbols after loading > ... > void* handle_julia = dlopen(LIBJULIAREPL, RTLD_NOW | RTLD_GLOBAL); > ... > typedef int (*t_jl_main)(int, char**); > t_jl_main jl_main = (t_jl_main)dlsym(handle_julia, "main"); > return jl_main(argc, argv); > ~~~ > > On linux, I get strange linker errors: > `/usr/bin/ld: repl.o: relocation R_X86_64_TPOFF32 against `tls_states.12084' > can not be used when making a shared object; recompile with -fPIC` > > As far as I can tell, julia uses fPIC throughout. Has anyone encountered > something like this before? Google links to some old gcc bugs and a go linker > issue but it's not evident if there is a fix. > > Cheers, > Joosep
