As k.org is migrating to FC13, I'm also adding an FC13 bochs to my
collection so that I can cut releases for 32-bit i?86 archs. I noticed
that the compilation fails with this:
LINK git-imap-send
/usr/bin/ld: imap-send.o: undefined reference to symbol 'EVP_DecodeBlock'
/usr/bin/ld: note: 'EVP_DecodeBlock' is defined in DSO
/lib/libcrypto.so.10 so try adding it to the linker command line
I understand that this is because the linker policy changed in the release
to make things safer. My understanding of the rationale for the change
goes like this:
When a binary (e.g. imap-send) wants a symbol X (e.g. EVP_DecodeBlock)
from a library A (e.g. -lcrypto), and the binary also wants a different
symbol from another library B (e.g. -lssl), and if the library B happens
to depend on library A, it used to be sufficient to link the binary with
library B, without explicitly linking it with library A, as library A
will be pulled in at the runtime because library B wants it anyway.
This however would break if library B stops depending on library A
(i.e. library B gets updated while remaining compatible with its own
older version, but its implementation no longer requries library A). It
is therefore safer to force programs to list their dependencies
explicitly at link time.
So, I need a patch like the following to make things compile on FC13.
Thoughts? Ideas for doing this (specifically, "make rpm") in better ways?
On my FC11 bochs and my other Linux boxes, the linker is loose but it does
not seem to hurt (and I do not think it should, as openssl-dev package
seems to have almost always shipped with both -lssl and -lcrypto) to add
this unconditionally.
diff --git a/Makefile b/Makefile
index 1f1ce04..18c7e8e 100644
--- a/Makefile
+++ b/Makefile
@@ -776,6 +776,7 @@ ifeq ($(uname_S),Linux)
NO_STRLCPY = YesPlease
NO_MKSTEMPS = YesPlease
HAVE_PATHS_H = YesPlease
+ NEEDS_CRYPTO_WITH_SSL = YesPlease
endif
ifeq ($(uname_S),GNU/kFreeBSD)
NO_STRLCPY = YesPlease
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html