Right, thanks for the tip. To confirm: `ui/repl.c` is still the code that gets compiled to the julia(-debug) binary, right? If I call "Base._start()" via libjulia, I still need to reproduce the usual argv logic of the julia binary. I'll just patch `repl.c` to my needs then without changing the linking, it's dirty but seems better that re-implementing.
On Sunday, 24 July 2016 20:43:54 UTC+2, Yichao Yu wrote: > > On Sun, Jul 24, 2016 at 2:39 PM, Yichao Yu <[email protected] <javascript:>> > wrote: > > On Sun, Jul 24, 2016 at 2:37 PM, Joosep Pata <[email protected] > <javascript:>> wrote: > >> I'd like to not re-implement all the REPL boiler-plate, like > >> ~~~ > >> ios_puts("\njulia> ", ios_stdout); > >> ios_flush(ios_stdout); > >> line = ios_readline(ios_stdin); > >> ~~~ > >> and so on. > > > > That's not the repl and you don't need to implement that. > > The only thing you need to do to get a repl after initialization is to > call `Base._start()`. Simply `jl_eval_string("Base._start()")` should > work. > > > > >> > >> In effect, I want to launch the usual julia REPL, but call some of my > own > > > > Which is **NOT** in the repl.c > > > >> initialization procedures before julia_init. > >> My motivation is that I want to call an external library that dies > horribly > >> due to the LLVM symbols present if loaded after julia_init is called, > see > >> also https://github.com/JuliaLang/julia/issues/12644. > >> The only way I've managed to do it is to recompile the julia binary, I > >> figured I could re-use the repl code by just dynamically loading it. > >> > >> On Sunday, 24 July 2016 19:55:00 UTC+2, Yichao Yu wrote: > >>> > >>> 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 >
