ccrtp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ccrtp-devel] Need to adapt configuration files for libgcrypt


From: David Sugar
Subject: Re: [Ccrtp-devel] Need to adapt configuration files for libgcrypt
Date: Sat, 10 Nov 2007 10:25:40 -0500
User-agent: Thunderbird 2.0.0.5 (X11/20070727)

Since the distributed tarball contains a pre-built configure, those
receiving tarballs will be fine so long as our default build machines
have a gcrypt recent enough on them or the missing .m4 files placed
there.  This will as you noted cause problems for those who use a
cvs/svn checkout directly and/or rebuild configure and do not have
current gcrypt, however.

I am assuming you are referring to "libgcrypt-devel" in terms of a
package on RPM based GNU/Linux distributions such as those provided by
RedHat, Mandriva, etc.  Generally when we build RPM spec files we assume
and require all devel packages to be present anyway, and in any case the
devel package would be needed to link and use gcrypt, so I do not see
this as a limiting issue by itself.  My concern is how this might effect
those building from checkout on machines with older releases of gcrypt
installed from before the macro was introduced.  I am also concerned
that it is being called a "AM_xxx" macro but yet is not distributed as
part of automake itself, as it does confuse where and when you can
expect to receive this macro.

An underlying assumption is that it will be used to test for a library
that may not be present, but yet forces one to provide the library to
rebuild configure to test for it's potential absence.  This to me seems
like a kind of funny circular dependency, especially given that our
packages only optionally use gcrypt rather than require it, and hence
this does require someone to install stuff to rebuild configure to check
for something they may not want to actually build the library with.
However, they could always run configure with options to disable
checking for gcrypt if that is desired, so you may be correct that the
impact could be rather minimal.

Where I might find it initially troublesome is on some of my test boxes,
for example for opensolaris, or some of the BSD's, or on my auto-build
system when rebuilding from cvs on an older distro, which may have older
distributions of gcrypt packaged and installed by default or may not
normally have gnupg/gcrypt installed at all.  I generally want to keep
the library versions and configurations of those boxes pure when
building packages to match the distro, and those are usually built
directly from svn checkout.  I could however add a local aclocal for my
build machines with this macro and modify some of my upper level stuff
to make sure it is parsed when rebuilding configure.

We actually do a similar check in GNU SIPWitch for gcrypt  (we use
gcrypt to optionally support SIP digest routines), so whatever we choose
to do for ccrtp will effect that package as well.  If the macro is small
enough and does something simple enough then maybe another option would
be to use a local version or embed the functionality directly in our
configure.ac script.

I will have to think about this and see what others might say.

Werner Dittmann wrote:
> David, all,
> 
> just recently the maintainer of libgcrypt (Werner Koch) released
> a new version. Because of this the "simple" detection of libgcrypt
> in the "configure.ac" script is not longer feasable. To
> correctly detect and configure the libraries and paths for libgcrypt
> the macro AM_PATH_LIBGCRYPT should be used. The libgcrypt-devel
> packet contains this macro and installs it in the correct m4 system
> directories.
> 
> The use of this macro implies that a system that runs the "reconfig"
> script to recreate the "configure" script needs the libgcrypt-devel
> packet. Would this be a severe constraint? IMHO it's not severe because
> libgcrypt is the basic crypto library for Gnu Privacy Guard (gpg) that
> is available for most systems (Linux, BSD, Windows, OS-X?).
> 
> Once "configure" was created it will detect if libgcrypt is available
> or not, and falls back to openssl if necessary.
> 
> If this modification is ok I would re-test the whole stuff on my system
> and then do a check-in.
> 
> Regards,
> Werner
> 
> 
> _______________________________________________
> Ccrtp-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/ccrtp-devel

Attachment: dyfet.vcf
Description: Vcard


reply via email to

[Prev in Thread] Current Thread [Next in Thread]