This appears to be the same issue as BZ553137, but under RHEL6.1. I have not duplicated the conditions of BZ553137 exactly, but I did trace my error using the debugger, with surprising results.

Description of problem:
When FIPS is enabled, aide cannot initialize its database

Version-Release number of selected component (if applicable):
aide-0.14-3.el6.i386
libgcrypt-1.4.5-5.el6_1.2.i686

Steps to Reproduce:
1. Boot in fips-compliant mode (fips=1 on kernel command line)
2. Run aide -i

Actual results:
* Error message on stderr:
libgcrypt selftest: binary  (0): No such file or directory
gcrypt_md_open failed
* Error message in /var/log/messages:
Jun  6 15:31:23 rhel6w-32 aide: Libgcrypt error: integrity check using `[?]' failed: No such file or directory
Jun  6 15:31:23 rhel6w-32 aide: Libgcrypt notice: state transition Self-Test => Error

Expected results:
Database initialized; no errors.


Additional info:
I installed the debuginfos and debugged with gdb, and here is what I found.

At fips.c:610, get_library_path("libgcrypt.so.11", "gcry_check_version", libpath, sizeof(libpath)) fails. (libpath is a null string at the time of the call; sizeof(libpath) is 4096.)

At fips.c:580, get_library_path calls dlopen(libname, RTLD_LAZY); libname is "libgcrypt.so.11".

Here's the interesting bit: the call to dlopen goes to a dlopen function defined at util.c:499, which just returns NULL. The comment immediately before that definition of dlopen says, "We need these dummy stubs to fool the linker into believing that we do not need them at link time."

Given that it appears this stub is what is actually called, rather than the real dlopen from libdl, the failure is unsurprising; but I do not know how to build libgcrypt properly to exclude the object code of this stub while still satisfying the linker as the comment says is necessary.