autoconf and shared library

[Matt Kowalczyk]

I hope I am posting this to the right newsgroup. I tried submitting this to the
(e-mail address removed) 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

 

[liljencrantz]

I hope I am posting this to the right newsgroup. I tried submitting this to the
(e-mail address removed) mailing list, but I see no activity. If this is the wrong
newsgroup, I would appriciate 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.

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?

See for example:

http://roo.no-ip.org/howtos/autoconf.php#head

You could bail out if the required functionality is missing using
something like:

# Search for specified function in specified libraries
AC_SEARCH_LIBS( [BK_set_key],
[crypto],
[],
[AC_MSG_ERROR( [Cannot find the libcrypto library, needed to build
this package.] )] )

You also need to remove the direct reference to libcrypto from your
Makefile.in and instead use @LDFLAGS@ for the above to work.

The above would work even if the libcrypto was missing but the
functionality lives in libc. It also works if the library lives in e.g.
/usr/local.

Thanks,
Matt

Hope this helps.

 

[Robert Gamble]

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?

Robert Gamble

 

[Richard G. Riley]

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

Robert Gamble

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

 

[Ben Pfaff]

I hope I am posting this to the right newsgroup. I tried
submitting this to the (e-mail address removed) mailing list, but I see
no activity.

There's plenty of activity on that mailing list, so you must be
doing something wrong.

 

[Robert Gamble]

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

I am not aware of any such all encompassing newsgroup nor am I
convinced there should be one. What is your point?

Robert Gamble

 

[Richard G. Riley]

I am not aware of any such all encompassing newsgroup nor am I
convinced there should be one. What is your point?

Robert Gamble

Point? I did not make a point. I asked if their was a general meeting
place for C programmers to discuss tools used to facilitate C
development. Looking back at the text above, I'm surprised it wasn't
relatively clear.

You can be sure I wasnt trying to convince you of anything.

 

[liljencrantz]

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

My bad. I am not subscribed to that mailing list, nor did I have the
subject of the original message, so doing the extra digging required
would have taken some additional effort, which is probably why the
thought never occured to me.

 

[Mark McIntyre]

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

 

[CBFalconer]

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.programming and comp.os.linux.misc would seem to
be suitable.

--
Some informative links:
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

 

[Matt Kowalczyk]

At a guess, comp.programming and comp.os.linux.misc would seem to
be suitable.

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

 

[Dave Thompson]

I hope I am posting this to the right newsgroup. I tried submitting this to the
(e-mail address removed) 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.net