Re: autoconf linking with shared object

[Ralf Wildenhues]

Hi Matt,

* Matt Kowalczyk wrote on Sat, Mar 25, 2006 at 09:35:22PM CET:
> 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

It's better to use `-lcrypto' instead of `/usr/lib/libcrypto.so'
(If the path weren't searched by default, like /usr/lib usually is, then
you would need to prepend `-L/usr/lib').

What's more, on some systems your command line will cause the entire
string `/usr/lib/libcrypto.so' to be hardcoded as library dependency
(DT_NEEDED on ELF), on others it won't.  For making sure libraries in
non-standard paths are found by the runtime linker, it helps to use a
macro like Gnulib's AC_LIB_LINKFLAGS (from the havelib module), or,
simpler but less portable, add `-R/lib/path'.  But for this library
I would not worry about it.

Not to forget that `-lcrypto' works with static libraries as well.

> 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.

Simply use
  AC_CHECK_LIB([crypto], [MD5_Init])

> 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.

This depends very much on the specific library: whether it is common
that it is installed already on systems, or a common addition, or
whether there is a free alternative you can easily point users to.

Writing replacement code yourself adds the burden of maintaining that
code as well, which is likely to be little tested, and thus has a high
chance of being buggy.  If you choose to do so, it may in any case
prove useful to try to share code, e.g., by using gnulib.

> Also, the location of my libcrypto.so object may differ from other peoples. 
> How do I deal with that?

See above.  It's common to allow the user to specify the location with
  configure CPPFLAGS="-I/path/to/include" LDFLAGS="-L/path/to/lib"

and then checking for libraries and headers should work ok.

Cheers,
Ralf