Hmmm, can you do a very simple compile?  Such as

#include <gcrypt.h>

int main() {
  gcry_md_open(NULL, 0, 0);
}

then compile

gcc foo.c -lgcrypt

internally, this is basically all configure is doing.

Can you show us the build issues with libgcrypt, the version you're using, and create a bug about it?  There are presently no known porting issues with it, so this may be new.

Lack of encryption effectively means that IPMI encryption using IPMI 2.0 (i.e. "LAN_2_0" for driver-type) cannot be used.  Non-encrypted network communication can be used (via IPMI 1.5 "LAN" or non-encrypted IPMI 2.0 connections), which is probably fine for sensors and power control and what not (which very few would likely care for the sensitivity of such data).

The most notable thing that cannot be used would be serial-over-lan or console access, such as with ipmiconsole, with encryption.  That is communication that users will care that network traffic is encrypted.

See the -I option in most tools to see about the unencrypted ciphers that can be used.

It should probably be noted that use of non-encrypted ciphers may depend on motherboard.  Some motherboards do not allow it at all.

All tools that are used locally on the local machine should not be affected at all.

My assumption is you are not building from source.  So this is a bit of a catch 22.

If FreeIPMI 1.4.9 has not yet been built for your distro and its particular glibc/libgcrypt versions, you are installing FreeIPMI versions for other distros/versions.  Thus it cannot work.

I would work with the upstream CentOS community to get a FreeIPMI 1.4.9 version built for the version you are using.

In the meantime, if you compile from source, it should work with whatever glibc/libgcrypt version you have installed.  If you cannot build, then we need to add the right portability into FreeIPMI.