On Sun, Jul 24, 2016 at 2:37 PM, Joosep Pata <[email protected]> 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.

>
> 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

Reply via email to