Description of problem: Installing both versions of the above packages (srtp-devel.x86_64 and srtp-devel.i686) for the purpose of cross-compiling is not possible as the config.h file is overwritten with the version of that file from the last arch installed. Cross-compilation is therefore going to FAIL as this file contains arch-specific settings, like "HAVE_X86" and SIZEOF_UNSIGNED_LONG. This is a *very* bad practice and should be avoided (see for a possible solution at the end). Version-Release number of selected component (if applicable): 1.4.4-1 How reproducible: Always Steps to Reproduce: 1. install both packages for the to 2 arches in question (x86_64 & i686) 2. 3. Actual results: in srtp/config.h there are two arch-specific settings: #define HAVE_X86 1 (for i686 arch) /* #undef HAVE_X86 */ (for x86_64 arch) and #define SIZEOF_UNSIGNED_LONG 4 (for i686 arch) #define SIZEOF_UNSIGNED_LONG 8 (for x86_64 arch) This is a recipe for disaster! Any cross-compilation will fail - miserably so - because of the above value being hardcoded. Expected results: Co-existence of both -devel packages to be made possible, allowing cross-compilation to succeed without any undesired side effects. Additional info: One possible solution I deploy in such circumstances is to rename the existing config.h to config-[arch-bits].h (i.e. config-32.h for 32-bit system and config-64.h for 64-bit system) and then use this as config.h: ===config.h==== /* This file is here to prevent a file conflict on multiarch systems. A * conflict will frequently occur because arch-specific build-time * configuration options are stored (and used, so they can't just be stripped * out) in config.h. The original config.h has been renamed. * DO NOT INCLUDE THE NEW FILE DIRECTLY -- ALWAYS INCLUDE THIS ONE INSTEAD. */ #ifdef srtp_multilib_redirection_h #error "Do not define srtp_multilib_redirection_h!" #endif #define srtp_multilib_redirection_h #if defined(__x86_64__) #include "srtp/config-64.h" #else #include "srtp/config-32.h" #endif #undef srtp_multilib_redirection_h ===============
libsrtp-1.4.4-4.20101004cvs.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/libsrtp-1.4.4-4.20101004cvs.fc16
libsrtp-1.4.4-4.20101004cvs.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/libsrtp-1.4.4-4.20101004cvs.fc17
libsrtp-1.4.4-4.20101004cvs.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/libsrtp-1.4.4-4.20101004cvs.el6
libsrtp-1.4.4-4.20101004cvs.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/libsrtp-1.4.4-4.20101004cvs.fc15
Package libsrtp-1.4.4-4.20101004cvs.fc16: * should fix your issue, * was pushed to the Fedora 16 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-4.20101004cvs.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-2148/libsrtp-1.4.4-4.20101004cvs.fc16 then log in and leave karma (feedback).
libsrtp-1.4.4-4.20101004cvs.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
libsrtp-1.4.4-4.20101004cvs.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
libsrtp-1.4.4-4.20101004cvs.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
libsrtp-1.4.4-4.20101004cvs.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.