On Sun, Jul 24, 2016 at 3:18 PM, Yichao Yu <[email protected]> wrote:
> On Sun, Jul 24, 2016 at 3:12 PM, Joosep Pata <[email protected]> wrote:
>> Right, thanks for the tip. To confirm: `ui/repl.c` is still the code that
>> gets compiled to the julia(-debug) binary, right?
>
> Yes.
>
>> 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.
>
> Sure, if you think literally two lines of code much worse than a dirty
> patching then go for it.

Sorry, 3 lines, to be more precise.

>
>>
>> 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]> wrote:
>>> > 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.
>>>
>>> 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

Reply via email to