On Sun, Jul 24, 2016 at 3:19 PM, Yichao Yu <[email protected]> wrote: > 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.
I was under the impression that by "patch repl.c" you mean to patch it somehow so that you can compile as a shared library, that will be very bad and is intentionally not supported. If you are talking about adding your llvm initialization stuff in this file and compile it still as an executable and if you current goal is to get a julia binary that does not confuse LLVM then I think that's the best way to do it and the approach itself is not "dirty" at all (apart from possibly dirty things you need to do to "unconfuse" LLVM, which you need to do anyway, independent of where you do it). >> >> 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
