Fixes for conda build

[isuruf]

@kpeeters, this is ready now

[isuruf]

After building both gtk and jupyter frontends with master, when starting the gtk frontend I get,

Kernel Crashed

The kernel crashed unexpectedly, and has been restarted. You will need to re-run all cells.

On terminal a bunch of message like the following are printed.

cadabra-client: connection to server on port 45691 failed

If I create a cadabra-server separately and connect to the port that it outputs, I get,

Received block with incorrect authentication token: .

[kpeeters]

When you run cadabra-server by hand, it should spit out something like

42291
4437afd2-759f-4f0c-a0ed-be6db82800f2

where the first line is the port number and the second the authentication token. Unfortunately, master does not have a way to set that token by hand when starting cadabra2-gtk. Give me a few hours to pull that from one of my development branches.

[kpeeters]

Github master now has functionality so that you can do (for the example in my earlier post)

cadabra2-gtk -s 42291 -t 4437afd2-759f-4f0c-a0ed-be6db82800f2

which should connect you to that running cadabra-server. If you run the server in a debugger you should be able to see what makes it crash/disconnect.

[isuruf]

Here's the backtrace, but I don't think it'll be helpful.

0x00007ffff7c829f8 in PyErr_Restore () from /home/isuru/miniconda3/envs/cadabra2/bin/../lib/libpython3.6m.so.1.0
(gdb) bt
#0  0x00007ffff7c829f8 in PyErr_Restore () from /home/isuru/miniconda3/envs/cadabra2/bin/../lib/libpython3.6m.so.1.0
#1  0x00005555555a45bc in Server::run_string (this=this@entry=0x7fffffffd700, blk=..., handle_output=handle_output@entry=true)
    at /usr/local/src/conda/cadabra2-split-2.2.8/client_server/Server.cc:176
#2  0x00005555555a4bf8 in Server::wait_for_job (this=0x7fffffffd700) at /usr/local/src/conda/cadabra2-split-2.2.8/client_server/Server.cc:291
#3  0x00007ffff77c3163 in std::execute_native_thread_routine (__p=0x555556607a10)
    at /home/conda/feedstock_root/build_artifacts/ctng-compilers_1578638331887/work/.build/x86_64-conda_cos6-linux-gnu/src/gcc/libstdc++-v3/src/c++11/thread.cc:80
#4  0x00007ffff78766db in start_thread (arg=0x7fffd9301700) at pthread_create.c:463
#5  0x00007ffff742b88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

[kpeeters]

The only difference that relates to python is your removal of the linking of cadabra2 to the python libraries. Can you try to see if the problem goes away if you reinstate that linking?

I do remember other problems of this type, with errors appearing in weird places, if you forget to link to python, on some platforms. So I wouldn't be surprised if this is the issue.

Why did you want to remove that explicit link to the python libraries in the first place?

[isuruf]

Because the python interpreter in conda (and some other distributions like ubuntu) is linked to libpython*.a instead of libpython*.so for performance reasons. When you have an extension module linked to libpython*.so, then there'll be symbol clashes and this usually leads to a segfault on macOS.

[kpeeters]

Yeah, but my modest attempt at creating a Conda package for the jupyter kernel (in the kpeeters channel) didn't show any such problems (before your patch went in), and that was tested on ubuntu.

Regardless whether it is the right solution, can you try whether it makes a difference? I'd like to know in which direction we need to search for the problem.

[isuruf]

Sure. I'll try now. One interesting thing I found is that if I disable the jupyter frontend, the gtk frontend works fine. So, it's an issue when both frontends are enabled.

[kpeeters]

There is one bit in client_server/CMakeLists.txt which starts

 print_header("Configuring Jupyter kernel build")

and contains some link_directories and include_directories which will influence the cadabra-server binary as well. So that might be the difference.

Can you check what is the difference in these two cases (with/without jupyter) between

ldd core/cadabra.so
ldd client_server/cadabra-server

? If they link to the same things with and without jupyter, then it must be that include path which pulls in things. Strictly speaking, neither of the two (link_directories and include_directories) should be necessary, if all the find_package things are correct.

[isuruf]

Without jupyter cadabra-server is linked to libsqlite3.so.0 and with jupyter, it's not. That's the only difference in cadabra-server. No difference in cadabra.so

[kpeeters]

I have pushed some changes which should remove this difference. Please try again. Neither should now link to libsqlite3.so.0 (it's not really needed for the server).

[kpeeters]

@isuruf Would you be able to update the conda packages to use a more recent cadabra version? One change which has gone in recently is that there is now a python-based jupyter kernel, which does not need xeus anymore, and will probably be maintained more consistently in the future than the old xeus-based kernel. It gets installed by default when you build cadabra (so even without -DENABLE_JUPYTER). I think this means we can get rid of or deprecate cadabra2-jupyter-kernel, as cadabra2 already has this new kernel.

[isuruf]

Sure, I'll add it to my long list of TODOs. It might take a while, so if you want to take a stab, send a PR to https://github.com/conda-forge/cadabra2-feedstock