Description of problem: oRTP from Linphone 3.6 requires patched libsrtp with renamed some internal functions whose name is conflicting with other libraries. Version-Release number of selected component (if applicable): libsrtp-1.4.4-7.20101004cvs.fc19 Actual results: oRTP build fails with error: This libsrtp version exports symbols conflicting with other libraries. Please use the one from git://git.linphone.org/srtp.git Please add this patch in Rawhide in F19 libsrtp builds (linphone 3.5 FTBS in F19 so 3.6 should be built for F19).
Created attachment 739562 [details] patch from git://git.linphone.org/srtp.git ommit 14027d37c7574b27bf22e57f508137b4e86b6466 Author: Simon Morlat <simon.morlat> Date: Wed Mar 27 20:31:39 2013 +0100 rename some internal functions whose name is conflicting with other librairies.
First, how does this patch affect other apps that use libsrtp? From what I can see asterisk, kdenetwork-kopete, and libjingle depend on it. ISTR that the chromium package that Tom Callaway is working on will require it as well. Second, it'd be better overall if libsrtp didn't have internal SHA1 and AES code. There are many crypto libraries out there to use. Some advantages would be reduced memory usage due to code sharing, code that is more highly optimized, ability to make use of specialized crypto hardware or GPUs, etc. Third, if no one is willing to replace the internal code with calls to an external library, the conflicting symbol names should be hidden from the linker by marking them with: __attribute__ ((visibility ("hidden"))) See http://gcc.gnu.org/wiki/Visibility for more information.
From appearances, the supplied patch is only touching internal functions, so the external api/abi should be unchanged. of course options 2,3 are better though, but let's not perfect be the enemy of the good.
Created attachment 739579 [details] patch that requires renaming ortp built successfully after I reverted this patch, so maybe it will work fine with unchanged libsrtp and this bug can be closed.
I don't think (In reply to comment #4) > Created attachment 739579 [details] > patch that requires renaming > > ortp built successfully after I reverted this patch, so maybe it will work > fine with unchanged libsrtp and this bug can be closed. Let me know if this patch is still needed. I don't have a problem applying the renaming patch, since I think those are all internal functions, but I don't want to apply it just for fun. :)
Symbol conflicts between libraries are very nasty, they can cause crashes when you least expect it. IMHO it's always a good idea to proactively rather than reactively prevent them.
linphone 3.7.0 beta switched from openssl to polarssl, so now no workaround for conflicting symbols libsrtp and polarssl. configure: error: This libsrtp version exports symbols conflicting with polar ssl, resulting in a bad execution path. Please use the one from git://git.linphone.org/srtp.git You could also track resolution of defect on https://github.com/cisco/libsrtp/issues/28 If you are not linking against polar ssl, you may prefer to skip this test with --enable-broken-srtp
Yes, please apply the patch from comment #4, it's really needed now. (Heh, I TOLD you it's better to do this proactively. :-) )
Sorry, I mean the patch from comment #1.
Created attachment 847422 [details] patch to avoid conflict with libzrtpcpp Yet one renaming from git://git.linphone.org/srtp.git commit d719bf1510a485b6760f76c95b8813bdc60781f6 Author: Johan Pascal <johan.pascal> Date: Fri Dec 27 00:47:36 2013 +0100 Rename internal function to avoid conflict with libzrtpcpp - aes_encrypt to srtp_aes_encrypt I don't know how essential this renaming now because ortp compilation fails.
libsrtp-1.4.4-10.20101004cvs.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/libsrtp-1.4.4-10.20101004cvs.fc19
libsrtp-1.4.4-10.20101004cvs.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/libsrtp-1.4.4-10.20101004cvs.fc20
Package libsrtp-1.4.4-10.20101004cvs.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libsrtp-1.4.4-10.20101004cvs.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-2282/libsrtp-1.4.4-10.20101004cvs.fc20 then log in and leave karma (feedback).
libsrtp-1.4.4-10.20101004cvs.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
libsrtp-1.4.4-10.20101004cvs.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.