autoconf and shared library

[Matt Kowalczyk]

I hope I am posting this to the right newsgroup. I tried submitting this to the
au******@gnu.or g mailing list, but I see no activity. If this is the wrong
newsgroup, I would appriciate a reference to a different source.

My question was:

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?

Second Question:

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

[Matt Kowalczyk]

CBFalconer wrote:

Mark McIntyre wrote:

"Richard G. Riley" <rg****@gmail.c om> wrote:

On 2006-03-26, Robert Gamble <rg*******@gmai l.com> wrote:

li********* *@gmail.com wrote:

>Matt Kowalczyk wrote:

>>I hope I am posting this to the right newsgroup. I tried
>>submittin g this to the au******@gnu.or g mailing list, but I
>>see no activity. If this is the wrong newsgroup, I would
>>appriciat e a reference to a different source.
>
>This is indeed the wrong newsgroup, but it seems you originally
>posted this in the correct one with no reply, which is a good
>enough excuse for me.

If this is the case, why wouldn't you post your response in the
correct forum where it would be on topic?

Out of curiosity where is the correct newsgroup for C programmers
to discuss (multi-platform) tools and libraries?

I doubt there is one - the details of tools tend to be discussed
either in groups specific to the tool (if they're in general enough
use) or in groups specific to the OS or compiler environment.

At a guess, comp.programmin g and comp.os.linux.m isc would seem to
be suitable.

I also got shutdown at comp.programmin g, I'll try the linux.misc.

[Dave Thompson]

On Sat, 25 Mar 2006 18:14:30 -0800, Matt Kowalczyk
<ma******@comca st.net> wrote:

I hope I am posting this to the right newsgroup. I tried submitting this to the
au******@gnu.or g mailing list, but I see no activity. If this is the wrong
newsgroup, I would appriciate a reference to a different source.

My question was:

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 <snip>
I was studying autoconf today and was wondering how I can <snip>
Is this possible?
Don't know.
Second Question:

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.

There is no single libcrypto.c. The source for openssl's crypto
library is BIG: the last time I looked, about a thousand files in a
few dozen directories with a good deal of interdependency and their
own complicated make-file scheme (not autoconf or automake). You
certainly could provide a copy of (or point to) the source tarball and
instruct users to install and build it, if on a system (or for Linux,
distro) that doesn't already have it but is supported.

Alternatively, if you need ONLY MD5, you could just use the reference
code in RFC 1321 (at rfc-editor.org or faqs.org or many other places)
or use or at least look at the (basically trivial) implementation in
GNU textutils (md5sum).

Incidentally, I assume you are aware that research in the past year
has found extremely cheap ways of generating collisions for MD5,
albeit of restricted form, so it is no longer safe for uses that
require collision resistance, and SHA-1 also appears to be seriously
weakened for such. Uses that require only 2nd-preimage resistance,
like HMAC and signing of data generated or significantly modified
especially randomized by the signer, still appear safe.

- David.Thompson1 at worldnet.att.ne t