Use dynamically linked libraries axc and omemo

[fortysixandtwo]

Hi,

as part of the DebianOnMobile team, we are aiming at bringing lurch into debian. See the packaging [1] which is currently in the NEW queue. This PR is related to [2] and [3]. In principle two things have been done to the Makefile:

• Switch to dynamically linked libraries for libaxc and libomemo.
• Order the .c files, so we can build reproducibly in debian (reprotest fails without this explicit ordering under the locale variation, because the `.cexpansion will be locale dependent resulting in different ordering of therodata` and other segments in the compiled binary

Cheers

PS: I have seen that there are already pull requests [4] and [5]. Would you be willing to carry the packaging from [1] upstream?

[1] https://salsa.debian.org/DebianOnMobile-team/purple-lurch [2] https://github.com/gkdr/axc/pull/17 [3] https://github.com/gkdr/libomemo/pull/30 [4] https://github.com/gkdr/lurch/pull/136 [5] https://github.com/gkdr/lurch/pull/141

[fortysixandtwo]

Hey @gkdr! Does the CI configuration live outside of the tree? (Because I haven't figured out where it might be coming from)

From looking at the log we would need to also install the dependencies libaxc-dev and libomemo-dev https://ci.appveyor.com/project/gkdr/lurch/builds/33903430#L96 Although I must say, I have no idea if those libraries are available in Ubuntu 1{6,8}.04 which seems being used in the CI (?)

[gkdr]

hi @fortysixandtwo, thanks for the contribution and sorry for taking so long to reply.

the CI config comes from the .appveyor.yml (which only exists in the dev branch currently). for the same reasons as in gkdr/axc#17 (i.e. the windows build), it would be better if the possibility to just statically link everything together remains intact. running the tests like that would also solve the problem with the CI.

[fortysixandtwo]

Sure thing, I'll cook something up and update it.

[Neustradamus]

Arch Linux: @freswa waits this PR.

• https://bugs.archlinux.org/task/69322

[gkdr]

hi @fortysixandtwo,

i just noticed you had another question i didn't answer. however, i also don't understand it. i was advised not to include packaging information in a repository like this. what would be the reason to include it after all, in your opinion?

[codecov-io]

Codecov Report

Merging #151 (19bc529) into dev (6b6cdca) will not change coverage. The diff coverage is n/a.

@@           Coverage Diff           @@
##              dev     #151   +/-   ##
=======================================
  Coverage   20.22%   20.22%           
=======================================
  Files           4        4           
  Lines        2309     2309           
=======================================
  Hits          467      467           
  Misses       1842     1842           

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 6b6cdca...19bc529. Read the comment docs.

[fortysixandtwo]

So I finally came around to updating the PR. Statically linking is now still possible and dynamic linking is only done if the required libraries have been found.

Regarding the packaging files: I don't really know what I was thinking "back then" and I don't think there is any upside to this :)

[gkdr]

thank you, i like the way the linking can be controlled! now i just gotta figure out why the hell the coverage changed :thinking:

[fortysixandtwo]

I shamelessly took inspiration from https://github.com/gkdr/axc/pull/17 for the general approach :)

[fortysixandtwo]

Regarding the coverage: Seems I needed to rebase against the dev branch, my bad!

[fortysixandtwo]

Leaving a friendly ping @gkdr

[gkdr]

thanks, i need that sometimes :grimacing: and thanks for figuring out the coverage, luckily it was easy enough :slightly_smiling_face:

[Neustradamus]

@gkdr: Thanks!