|
From: | Matt Kowalczyk |
Subject: | autoconf linking with shared object |
Date: | Sat, 25 Mar 2006 12:35:22 -0800 |
User-agent: | Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) |
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
[Prev in Thread] | Current Thread | [Next in Thread] |