One of my source files uses the library:
#include <openssl/md5.h>
This forces me to add /usr/lib/libcrypto.so to the gcc command when I link the
object to produce an executable for instance. My gcc command looks something
like below:
gcc --pedantic -Wall -std=c99 -O2 -g -O2 /usr/lib/libcrypto.so -o main Main.o
my_md5.o
I was studying autoconf today and was wondering how I can assert that the user
compiling does in fact have the libcrypto.so shared object.
e.g. ./configure would check to make sure libcrypto.so is available... at least
it's functionality--the function MD5_Init is defined for example.
Is this possible?
As programs grow in complexity and require many of these shared objects, what is
the best way to assure portability? Do I include the code for libcrypto.c for
the user to compile if they don't have libcrypto.so? Or do I provide the user
with an unfriendly error message from the compiler.
Also, the location of my libcrypto.so object may differ from other peoples. How
do I deal with that?
Thanks,
Matt
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
