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

[Werner Dittmann]

David,

the macro is fairly simple, not really big (even I understand what
this macro does :-) ). So, probably I could copy it into the local
m4 directory, rename it for example to "local_libgcrypt.m4" and also
rename the macro names if necessary to avoid confusion with the
original macro. Thus we have a local implementation. Putting in the
refrence to the original macro would enable us to track this.

Unfortunatly libgcrypt also uses a non-standard way for pkg-config, it
has its own mechanisms (shell script) that the libgcryt package installs
(usually in /usr/bin). This is called "libgcrypt-config". This is why
the maintainer also introduced an own macro.

IMHO having a local copy is the safest way - on the other hand yet
another additional unnecessary "manual" dependency to maintain. I also
was puzzeled when I discovered this circular dependency you mentioned.
I'll contact Werner Koch to see if he has some ideas how to solve this
problem.

Regards,
Werner

David Sugar schrieb:
> 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