I’ve put a lot of effort in trying to package https://jami.net - a distributed messaging application & platform, from GNU. Overall, I’m able to build everything fine - the daemon, the client library etc. There’s only one critical error, when I try to run the daemon:
$ ./result/lib/ring/dring
==27318==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
Run the daemon with a proper LD_PRELOAD in the environment, according to this - that made it at least run, but it segfaults when it exited and clients that connected to it also crashed.
I would have left this quest alone since upstream doesn’t seem responsive, and if I hadn’t felt I was so close, and that I’m missing something Guix seemed to have solved.
I tried building the jami packages from your package-jami-dirty branch on github. I was able to reproduce the same issue you described. I examined the binary and its dependencies using ldd and readelf. The library which depends on libasan appears to be opendht. A quick look at the opendht derivation shows this CMake argument:
"-DOPENDHT_SANITIZE=ON"
…which smells very much like the culprit (haven’t tried removing it or setting it to OFF and rebuilding to confirm yet). Git tells me you added the CMake args. Did you add that one for a specific reason, or are they copied from somewhere else?
As Jon says, the sanitizers are usually debugging tools, designed to catch buffer overflows and other subtle bugs. They slow things down a little bit, so you don’t normally want them turned on in release builds.
I tried removing "-DOPENDHT_SANITIZE=ON", and confirmed that it does fix the libasan issue: the dring binary appears to run.
It does appear to have gcov coverage enabled though, which is another thing that isn’t usually meant to be enabled in release builds (GCov is a code coverage tool: typically you run your test suite with it turned on and it tells you which lines of your code were actually executed, giving you a rough idea how much of your code is covered by the unit tests (and which bits definitely aren’t covered)). This means that when it exits it tries to write a bunch of .gcda files (and fails because the location it tries to write them to doesn’t exist). Not sure how to turn it off in this case…
@Thra11 your help is spectacular. I was able to build it as well now when opendht was compiled without that flag. TBH I added it because I saw it as an optional feature which might worth something for jami, I didn’t understand it’s meaning at the time. Currently the opendht derivation of at package-jami-dirty uses cmake while upstream uses autotools but the ./configure flags they use for jami suppose to be equivalent to what’s used currently. For reference:
After all this which seemed to indicate success, I tried to create an account with the gnome client jami-gnome while the daemon was running and it hanged there indefinitely.
The story with their release procedure is super confusing - opendht passed the tests just a few commits ago, but it doesn’t now in it’s latest master. I give up, once more.