To test, I uninstalled libotr5 from my debian system. When running a plain local build of comm-beta, the OTR functionality was disabled (missing UI elements). Then I copied all files from the attached artifact file to my dist/bin directory (ignoring the subfolder form the .tar.xz). This worked, using strace I saw that the libotr.so.5 from dist/bin was loaded. I couldn't test the gcrypt and gpg-error modules. Those are difficult to uninstall on a Linux system, because much of the base environment depends on it. When using strace to follow the .so files loaded by the Thunderbird process, those two libraries are loaded very early. The libotr.so.5 modules is loaded much later. For Linux, the gcrypt and gpg-error modules we'll ship will likely be only used in fallback scenarios, if the system libraries aren't available for any reason. Testing the Windows platform will be more interesting.
Bug 1518166 Comment 24 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
To test, I uninstalled libotr5 from my debian system. When running a plain local build of comm-beta, the OTR functionality was disabled (missing UI elements), as expected. Then I copied all files from the attached artifact file to my dist/bin directory (ignoring the subfolder form the .tar.xz). This worked, using strace I saw that the libotr.so.5 from dist/bin was loaded. I couldn't test the gcrypt and gpg-error modules. Those are difficult to uninstall on a Linux system, because much of the base environment depends on it. When using strace to follow the .so files loaded by the Thunderbird process, those two libraries are loaded very early. The libotr.so.5 modules is loaded much later. For Linux, the gcrypt and gpg-error modules we'll ship will likely be only used in fallback scenarios, if the system libraries aren't available for any reason. Testing the Windows platform will be more interesting.