OpenSSL's libcrypto always defines AES symbols with the same names as qemu's local aes code. This is problematic when enabling at least curl as that frequently also uses libcrypto. It might not be noticed when running, but if you try to statically link, everything falls down. An example snippet: LINK qemu-nbd .../libcrypto.a(aes-x86_64.o): In function 'AES_encrypt': (.text+0x460): multiple definition of 'AES_encrypt' crypto/aes.o:aes.c:(.text+0x670): first defined here .../libcrypto.a(aes-x86_64.o): In function 'AES_decrypt': (.text+0x9f0): multiple definition of 'AES_decrypt' crypto/aes.o:aes.c:(.text+0xb30): first defined here .../libcrypto.a(aes-x86_64.o): In function 'AES_cbc_encrypt': (.text+0xf90): multiple definition of 'AES_cbc_encrypt' crypto/aes.o:aes.c:(.text+0xff0): first defined here collect2: error: ld returned 1 exit status .../qemu-2.6.0/rules.mak:105: recipe for target 'qemu-nbd' failed make: *** [qemu-nbd] Error 1 The aes.h header has redefines already for FreeBSD, but go ahead and enable that for everyone since there's no real good reason to not use a namespace all the time. Signed-off-by: Mike Frysinger <vapier@chromium.org> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> |
||
---|---|---|
.. | ||
aes.h | ||
afsplit.h | ||
block.h | ||
cipher.h | ||
desrfb.h | ||
hash.h | ||
init.h | ||
ivgen.h | ||
pbkdf.h | ||
random.h | ||
secret.h | ||
tlscreds.h | ||
tlscredsanon.h | ||
tlscredsx509.h | ||
tlssession.h | ||
xts.h |