[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Pkg-julia-devel] julia_1.0.0-1_amd64.changes REJECTED



Hi,

On Thu, Dec 20, 2018 at 09:29:15PM +0100, Ansgar Burchardt wrote:
> Hi,
> 
> Mo Zhou writes:
> > Another fortnight has passed. Any update?
> 
> Sorry for taking so long; I wanted to put this on our meeting agenda,
> but currently don't find much time...
>
> Anyway, the package is now marked to be accepted.

Your surprisingly quick response is much appreciated. Thanks!

> There were some misunderstandings on our side why debug symbols weren't
> stripped and from discussion I'm not sure it is clear why, but we agree
> that this shouldn't block the current version and should better be
> discussed in a bug report.

Well, sometimes I struggle with language barrier when trying to
explain things clear. That said, let's look at the importance of
debugging symbols from a *user's* point of view.

First, from a user's point of view Julia is an interpreted language
even if it compiles a lot at run time through JIT. Julia sysimage,
i.e. the unstripped sys.so aims to reduce the runtime compilation
overhead through AOT (Ahead-Of-Time) compilation, which feels like
sort of JIT cache in the ELF shared object format.

Now let's take a look at
  https://docs.julialang.org/en/v1.0.0/manual/stacktraces/
and get a stacktrace in Julia REPL following the official doc:


  ⛬ > stacktrace()
  5-element Array{Base.StackTraces.StackFrame,1}:
   top-level scope at none:0
   eval(::Module, ::Any) at boot.jl:319
   eval_user_input(::Any, ::REPL.REPLBackend) at REPL.jl:85
   macro expansion at REPL.jl:117 [inlined]
   (::getfield(REPL, Symbol("##28#29")){REPL.REPLBackend})() at task.jl:259


And I must emphasize that all *.jl files are scripts, not code to
be compiled from user's point of view. These scripts are shipped
by the julia-common package.

Then let's strip the sys.so and execute the above function again:


  /u/l/x/julia ❯❯❯ sudo cp sys.so sys.so.bak 
  /u/l/x/julia ❯❯❯ sudo strip sys.so

  ⛬ > stacktrace()
  1-element Array{Base.StackTraces.StackFrame,1}:
   top-level scope at none:0


Well, you would must be disappointed if an interpreter e.g. python
cannot trace into a script, including the standard library of the
language itself. I mean, if python were julia, the above snippet means
python cannot trace into it's own standard library (written in python
script) anymore after stripping the sysimage. Isn't that ridiculous?


Apart from that, Julia users can manually compile the Julia base and
stdlib scripts to reflect changes (although this sounds weird):
(these commands are borrowed from [1])


  cd /usr/share/julia/base/
  julia -C native --output-ji ~/JL/basecompiler.ji --output-o ~/JL/basecompiler.o compiler/compiler.jl
  julia -C native --output-ji ~/JL/sys.ji --output-o ~/JL/sys.o -J ~/JL/basecompiler.ji --startup-file=no sysimg.jl
  gcc -shared '-DJULIAC_PROGRAM_LIBNAME="/home/lumin/JL/sys.so"' -o ~/JL/sys.so -Wl,--whole-archive ~/JL/sys.o -Wl,--no-whole-archive -std=gnu99 -I/usr/include/julia -DJULIA_ENABLE_THREADING=1 -fPIC -L/usr/lib/x86_64-linux-gnu -Wl,--export-dynamic -Wl,-rpath,/usr/lib/x86_64-linux-gnu -Wl,-rpath,/usr/lib/x86_64-linux-gnu/julia -ljulia -m64

---

I'd redirect this topic to BTS in case where there are still people
who doubt this decision.

[1] https://github.com/JuliaLang/PackageCompiler.jl


Reply to: