I am trying to install Iroha on Raspberry pi 3 and 4. I am manually building it as following:
1) git clone -b master https://github.com/hyperledger/iroha
cd iroha
mkdir build; cd build; cmake ..; make -j$(nproc)
and then i get the following error
CMake Error at cmake/dependencies.cmake:24 (find_package):
Could not find a package configuration file provided by "spdlog" (requested
version 1.3.1) with any of the following names:
spdlogConfig.cmake
spdlog-config.cmake
Add the installation prefix of "spdlog" to CMAKE_PREFIX_PATH or set
"spdlog_DIR" to a directory containing one of the above files. If "spdlog"
provides a separate development package or SDK, be sure it has been
installed.
Call Stack (most recent call first):
CMakeLists.txt:179 (include)
– Configuring incomplete, errors occurred!
See also "/home/pi/Desktop/iroha/build/CMakeFiles/CMakeOutput.log".
See also "/home/pi/Desktop/iroha/build/CMakeFiles/CMakeError.log"
Any idea how to solve this?
I've managed to build iroha (version 1.1.3) on RPI 4 on Ubuntu Server 20.04.1 LTS (GNU/Linux 5.4.0-1015-raspi aarch64)
First of all we need to update our system:
sudo apt-get update
sudo apt-get upgrade -y
Then we should install dependencies according to instruction:
sudo apt-get -y --no-install-recommends install build-essential git ca-certificates tar curl unzip cmake vim ninja-build -y
Now I suggest to reboot system:
sudo reboot now
Next step was to download iroha source, I've tested this on Iroha 1.1.3, so my source was:
git clone --branch 1.1.3 https://github.com/hyperledger/iroha.git --depth=1
Next step according to instruction is to call:
iroha/vcpkg/build_iroha_deps.sh
But when I was building with the script on October 2020 some extra steps was necessarily, it was because of facts that:
vcpkg does not support aarch64,
g++ on RPI does not have flag -m64
one of dependency (GRPC) downloaded by VCPKG was not compiling
When You build this after some time possibly you will not face any of those problems, but it is also possible that You are going to face different problems.
So first step of building on RPI is to just run command:
iroha/vcpkg/build_iroha_deps.sh
and wait. If you don't see any problems you don't need the instruction.
If You see problem with cmake connected with vcpkg it means that vcpkg still doesn't support aarch64, but there is a hack to use system's cmake, instead of downloaded by vcpkg. To do this we need to add -useSystemBinaries to the file iroha/vcpkg/build_iroha_deps.sh after command bootstrap-vcpkg.sh. It can be done fast with command:
sed -i 's/\(^.*bootstrap.*$\)/\1 -useSystemBinaries/g' iroha/vcpkg/build_iroha_deps.sh
Then you can resume building:
./vcpkg/vcpkg install $(cat iroha/vcpkg/VCPKG_DEPS_LIST | cut -d':' -f1 | tr '\n' ' ')
./vcpkg/vcpkg install --head $(cat iroha/vcpkg/VCPKG_HEAD_DEPS_LIST | cut -d':' -f1 | tr '\n' ' ')
If you face problem with building boost-container, connected with flag -m64, which does not exist on gcc at RPI, you need to create wrapper to remove the flag. I've created the wrapper in c++ (file g++wrapper.cc):
#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <string>
using namespace std;
string args2Text(int argc, char** argv, const char* forbiddenFlag="-m64", const char* compilerCommand="/usr/bin/g++");
int returnValidNumberFromSubcommand(int systemCallReturnValue);
string escapeQuotes(const string& text);
int main(int argc, char* argv[])
{
const auto command = args2Text(argc, argv);
const auto status = system(command.c_str());
return returnValidNumberFromSubcommand(status);
}
string args2Text(int argc, char** argv, const char* forbiddenFlag, const char* compilerCommand)
{
string command = compilerCommand;
for (int i = 1; i < argc; ++i)
{
if (strcmp(argv[i], forbiddenFlag))
command += " "s + escapeQuotes(argv[i]);
}
return command;
}
string escapeQuotes(const string& text)
{
constexpr const char* escapedQuote = R"_(\")_";
string returnString;
returnString.reserve(text.size() + 2);
for (auto c : text)
{
if ('"' == c)
returnString += escapedQuote;
else
returnString += c;
}
return returnString;
}
int returnValidNumberFromSubcommand(int systemCallReturnValue)
{
if (systemCallReturnValue < 0)
{
return -1;
}
else
{
if (WIFEXITED(systemCallReturnValue))
{
return WEXITSTATUS(systemCallReturnValue);
}
else
{
return 1;
}
}
}
just compile that: g++ g++wrapper.cc -o g++wrapper
We just need to replace system's /usr/bin/c++ with our wrapper, we can do that with commands:
sudo mv /usr/bin/c++ /usr/bin/c++_original
sudo mv g++wrapper /usr/bin/c++
Now we can resume building now as above.
When we face problem with building GRPC:
-- Using source at /home/ubuntu/vcpkg/buildtrees/grpc/src/577f0c79b1-086c8c6e6c
-- Configuring x64-linux-dbg
-- Configuring x64-linux-rel
-- Building x64-linux-dbg
CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:134 (message):
Command failed: /usr/bin/cmake;--build;.;--config;Debug;--target;install;--;-v
Working Directory: /home/ubuntu/vcpkg/buildtrees/grpc/x64-linux-dbg
See logs for more information:
/home/ubuntu/vcpkg/buildtrees/grpc/install-x64-linux-dbg-out.log
And check in the log file:
/home/ubuntu/vcpkg/buildtrees/grpc/install-x64-linux-dbg-out.log
/home/ubuntu/vcpkg/buildtrees/grpc/src/577f0c79b1-086c8c6e6c/src/core/lib/iomgr/ev_epollex_linux.cc:1105:13: error: ambiguating new declaration of ‘long int gettid()’
Then I've fixed with commenting gettid function redefinition:
sed -i 's_\(^.*long gettid(.*$\)_//\1_g' $(find . -name ev_epollex_linux.cc)
Then I've faced similar problem with another definition of function gettid, so I did similar:
sed -i 's_\(^.*long gettid(.*$\)_//\1_g' $(find . -name log_linux.cc)
After correcting we can resume building.
If everything is all right and we wrapped c++ command with our binary we should restore original command:
sudo mv /usr/bin/c++_original /usr/bin/c++
Then we should be able to compile dependencies to iroha. Now according to instruction2 we should find out what cmake's flag we need, we can do this with command:
vcpkg/vcpkg integrate install
in my situation it was printed:
-DCMAKE_TOOLCHAIN_FILE=/home/ubuntu/vcpkg/scripts/buildsystems/vcpkg.cmake
Now we can use this in cmake's command.
cd iroha
cmake -H. -Bbuild -DTESTING=OFF \
-DVCPKG_TARGET_TRIPLET=x64-linux \
-DCMAKE_TOOLCHAIN_FILE=/home/ubuntu/vcpkg/scripts/buildsystems/vcpkg.cmake
Then lets call makefile (I suggest single thread on RPI):
cd build
make
sudo make install
If succesfull great! But is you see problem:
CMake Error at cmake_install.cmake:78 (file):
file INSTALL cannot find "/home/ubuntu/iroha/-lpthread": No such file or directory
You need to comment that line from the file:
sed -i 's_\(^.*\-lpthread.*\)$_#\1_g' cmake_install.cmake
Then we can rerun:
sudo make install
Thats all about building Iroha on Raspberry Pi 4, now You can install (or use docker image) database and enjoy.
Related
I have found similar posts but they are rather old and they sadly did not solve my issue.
I am trying to add a Gateway for my GoLang GRPC services
PROJ_PATH=${CURDIR}
.PHONY: proto
proto: ## Generate protobuf code
# Compile proto files inside the project.
protoc api.proto --proto_path=${PROJ_PATH}/proto --go_out=. --go-grpc_out=. \
--grpc-gateway_out . \
--grpc-gateway_opt generate_unbound_methods=true \
--openapiv2_out . \
--openapiv2_opt logtostderr=true \
--openapiv2_opt generate_unbound_methods=true
I add the two dependencies
go get github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-grpc-gateway
go get github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-openapiv2
But I still get his error
protoc-gen-grpc-gateway: program not found or is not executable
Please specify a program using absolute path or make sure the program is available in your PATH system variable
--grpc-gateway_out: protoc-gen-grpc-gateway: Plugin failed with status code 1.
make: *** [proto] Error 1
I had to remove the import and gateway options in the GRPC file because this error so it looks like I have the wrong plugin but reading here tells me otherwise.
google/api/annotations.proto: File not found.
api.proto:5:1: Import "google/api/annotations.proto" was not found or had errors.
make: *** [proto] Error 1
syntax = "proto3";
option go_package = "pkg/api";
import "google/api/annotations.proto"; <---- had to remove
service ApiService {
rpc Test(TestRequest) returns (TestResponse){
option (google.api.http) = { <---- had to remove
get: "/v1/test"
body: "*"
};
}
}
Any advice would be greatly appreciated.
---- solved with ------
go install \
github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-grpc-gateway#latest \
github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-openapiv2#latest
then add the path to the proto command
--plugin=protoc-gen-grpc-gateway=${GOPATH}/bin/protoc-gen-grpc-gateway \
full command...
protoc api.proto --proto_path=${PROJ_PATH}/proto --go_out=. --go-grpc_out=. \
--grpc-gateway_out . \
--grpc-gateway_opt generate_unbound_methods=true \
--plugin=protoc-gen-grpc-gateway=${GOPATH}/bin/protoc-gen-grpc-gateway \
--openapiv2_out . \
--openapiv2_opt logtostderr=true \
--openapiv2_opt generate_unbound_methods=true
I had to install the binary like so
go install \
github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-grpc-gateway#latest \
github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-openapiv2#latest
Then update the proto command with the path.
--plugin=protoc-gen-grpc-gateway=${GOPATH}/bin/protoc-gen-grpc-gateway \
Full proto command
PROJ_PATH=${CURDIR}
.PHONY: proto
proto: ## Generate protobuf code
# Compile proto files inside the project.
protoc api.proto --proto_path=${PROJ_PATH}/proto --go_out=. --go-grpc_out=. \
--grpc-gateway_out . \
--grpc-gateway_opt generate_unbound_methods=true \
--plugin=protoc-gen-grpc-gateway=${GOPATH}/bin/protoc-gen-grpc-gateway \
--openapiv2_out . \
--openapiv2_opt logtostderr=true \
--openapiv2_opt generate_unbound_methods=true
Does any know of any good instructions explaining how to implement bluetooth into a yocto build.
I've added bluetooth into the MACHINE variable within the machine.conf and bluez to CORE_IMAGE_EXTRA_INSTALL in the local.conf located in my build directory. After building a new image, bluetoothd won't start because this condition is not met ConditionPathIsDirectory=/sys/class/bluetooth which is correct because that location doesn't exist on my system.
I'm new to yocto so any guidance would be greatly appreciated.
EDIT
So the /conf/bblayers has the following content:
BBLAYERS ?= " \
${BSPDIR}/poky/meta \
${BSPDIR}/poky/meta-poky \
${BSPDIR}/poky/meta-yocto-bsp \
${BSPDIR}/meta-atmel \
${BSPDIR}/meta-openembedded/meta-oe \
${BSPDIR}/meta-openembedded/meta-networking \
${BSPDIR}/meta-openembedded/meta-python \
${BSPDIR}/meta-openembedded/meta-multimedia \
${BSPDIR}/meta-swupdate \
${BSPDIR}/meta-custom \
${BSPDIR}/meta-openembedded/meta-initramfs \
The local.conf contains:
CORE_IMAGE_EXTRA_INSTALL += "\
bluez5 \
rpm \
valgrind \
"
DISTRO_FEATURES_append = " systemd bluetooth"
DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
VIRTUAL-RUNTIME_init_manager = "systemd"
VURTUAL-RUNTIME_initscripts = "systemd-compat-units"
The .inc file in my custom layer contains:
#IMAGE_FEATURES += "ssh-server-openssh package-management"
IMAGE_INSTALL = "\
packagegroup-core-boot \
packagegroup-core-full-cmdline \
packagegroup-base-bluetooth \
kernel-modules \
libgpiod \
ntp \
sqlite3 \
openssl \
mtd-utils \
${CORE_IMAGE_EXTRA_INSTALL} \
"
inherit core-image
The machine conf file contains:
MACHINE_FEATURES = "apm ext2 ext3 pcmcia usbhost usbgadget"
Running
bitbake -e packagegroup-base | grep ^ADD_BT
Returns
ADD_BT="packagegroup-base-bluetooth"
bitbake -e <image-name> | grep ^IMAGE_INSTALL=
Returns
IMAGE_INSTALL=" packagegroup-core-boot packagegroup-core-full-cmdline packagegroup-base-bluetooth kernel-modules libgpiod ntp sqlite3 openssl mtd-utils apg-st-databases bluez5 rpm valgrind "
bitbake -e packagegroup-base-extended | grep ^RDEPENDS_packagegroup-base-extended=
returns
RDEPENDS_packagegroup-base-extended=" packagegroup-base packagegroup-base-wifi packagegroup-base-bluetooth "
First of all, MACHINE is dedicated to have one value which is the configuration file for your board, and you can not add bluetooth to it.
Yocto has an automatic bluetooth feature that handles adding bluetooth into your build. But it only there for boards that have a builtin bluetooth module.
For more info, check the machine features in the official Yocto doc here.
Let me now explain how bluetooth is integrated:
Basically, you only need some kernel defconfig configuration and bluez5 utility.
If you add the following line to local.conf or your custom machine file:
DISTRO_FEATURES_append = " bluetooth"
it will take effect if you build image that is based on core-image class, like core-image-minimal, because it contains a packagegroup-base-bluetooth as follows:
SUMMARY_packagegroup-base-bluetooth = "Bluetooth support"
RDEPENDS_packagegroup-base-bluetooth = "\
bluez5 \
"
RRECOMMENDS_packagegroup-base-bluetooth = "\
kernel-module-bluetooth \
kernel-module-l2cap \
kernel-module-rfcomm \
kernel-module-hci-vhci \
kernel-module-bnep \
kernel-module-hidp \
kernel-module-hci-uart \
kernel-module-sco \
${#bb.utils.contains('COMBINED_FEATURES', 'usbhost', 'kernel-module-hci-usb', '',d)} \
${#bb.utils.contains('COMBINED_FEATURES', 'pcmcia', 'kernel-module-bluetooth3c-cs', '',d)} \
${#bb.utils.contains('COMBINED_FEATURES', 'pcmcia', 'kernel-module-bluecard-cs', '',d)} \
${#bb.utils.contains('COMBINED_FEATURES', 'pcmcia', 'kernel-module-bluetoothuart-cs', '',d)} \
${#bb.utils.contains('COMBINED_FEATURES', 'pcmcia', 'kernel-module-dtl1-cs', '',d)} \
"
It will add packagegroup-base-bluetooth only in two conditions:
If bluetooth in DISTRO_FEATRUES and not in MACHINE_FEATURES and one of (pcmcia, pci or usbhost) in MACHINE_FEATURES
If bluetooth in COMBINED_FEATURES.
For more info on COMBINED_FEATURES check this link.
So, you just need to make true one of the conditions.
You can dig in more to understand more details, check:
poky/meta/classes/core-image.bbclass
poky/meta/recipes-core/packagegroups/packagegroup-base.bb
NOTE
If your bluetooth module has a dedicated kernel driver for example, you need to activate it in the kernel configuration via a fragment file.
Or create a module recipe for it.
EDIT
In order to add bluetooth just:
DISTRO_FEATURES_append = " bluetooth"
after that, you can check that bluetooth package is added. Here are details:
packagegroup-base-extended is always added to images based on core-image.bbclass and here is its content:
RDEPENDS_packagegroup-base-extended = "\
packagegroup-base \
${ADD_WIFI} \
${ADD_BT} \
${ADD_3G} \
${ADD_NFC} \
"
You see the ADD_BT variable? It is by default empty, and it is filled with packagegroup-base-bluetooth only if the first condition is true, and here is the detail from the recipe:
if "bluetooth" in distro_features and not "bluetooth" in machine_features and ("pcmcia" in machine_features or "pci" in machine_features or "usbhost" in machine_features):
d.setVar("ADD_BT", "packagegroup-base-bluetooth")
Now, to check that it is added, run:
bitbake -e packagegroup-base | grep ^ADD_BT
you should see: ADD_BT="packagegroup-base-bluetooth"
Also, you can check that packagegroup-base-extended is added to your image:
bitbake -e <your_image> | grep ^IMAGE_INSTALL=
Also, you can check if packagegroup-base-extended has packaged bluetooth package with it:
bitbake -e packagegroup-base-extended | grep ^RDEPENDS_packagegroup-base-extended=
EDIT2:
Your configuration looks okay, specially when packagegroup-base-bluetooth is shipped with in IMAGE_INSTALL.
I have some comments that you need to consider anyways:
local.conf:
Remove bluez5 from CORE_IMAGE_EXTRA_INSTALL
Change:
DISTRO_FEATURES_append = " systemd bluetooth"
DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
VIRTUAL-RUNTIME_init_manager = "systemd"
VURTUAL-RUNTIME_initscripts = "systemd-compat-units"
with:
INIT_MANAGER = "systemd"
DISTRO_FEATURES_append = " bluetooth"
In your custom image file:
Put inherit core-image before IMAGE_INSTALL, because IMAGE_INSTALL of core-image will not take effect because it is ?=. So:
inherit core-image
IMAGE_INSTALL += "\
packagegroup-core-full-cmdline \
kernel-modules \
libgpiod \
ntp \
sqlite3 \
openssl \
mtd-utils \
"
Now, the only part that mention bluetooth is :
DISTRO_FEATURES_append = " bluetooth"
Now, check again for the variable tests.
This is not as simple as adding bluetooth as a DISTRO_FEATURE. Adding this only adds the systemd service and other user-space tools to the build. In fact, what you really need is your Linux kernel to support Bluetooth (i.e. add the necessary drivers and configuration to the Linux Kconfig). It can be done by means of enabling CONFIG_BT through menuconfig or directly on your config file. Additionally, you might want to include kernel drivers/plugins for the specific Bluetooth hardware you are using.
For /sys/class/bluetooth to exist, the kernel module bluetooth.ko, which is only autoloaded by systemd-udev if it actually finds a working Bluetooth hardware device.
I suggest you start by adding support for Bluetooth on your Linux kernel, recompiling and reflashing. Then all your user-space tools should start working if your BT hardware is able to be brought up.
This is a good resource that may help you: https://wiki.archlinux.org/title/bluetooth#Troubleshooting
Following these instructions
to install the RSK node on an 2021 MBP with Apple M1 Pro chip.
I would like to run an RSK node locally in regtest mode.
After installation, running the command to start RSKj:
java \
-classpath ~/.rsk/rskj-core-3.1.0-IRIS-all.jar \
-Drpc.providers.web.cors=\* \
-Drpc.providers.web.ws.enabled=true \
co.rsk.Start \
--regtest
... results in the following error:
Exception in thread "main" java.lang.UnsatisfiedLinkError: Could not load library. Reasons: [no leveldbjni in java.library.path, /private/var/folders/40/k7t383452q75nkmr_5kl12_80000gn/T/libleveldbjni-64-8276576211622720497.jnilib: dlopen(/private/var/folders/40/k7t383452q75nkmr_5kl12_80000gn/T/libleveldbjni-64-8276576211622720497.jnilib, 0x0001): tried: '/private/var/folders/40/k7t383452q75nkmr_5kl12_80000gn/T/libleveldbjni-64-8276576211622720497.jnilib' (fat file, but missing compatible architecture (have 'x86_64,i386', need 'arm64e')), '/usr/lib/libleveldbjni-64-8276576211622720497.jnilib' (no such file)]
at org.fusesource.hawtjni.runtime.Library.doLoad(Library.java:182)
at org.fusesource.hawtjni.runtime.Library.load(Library.java:140)
at org.fusesource.leveldbjni.JniDBFactory.<clinit>(JniDBFactory.java:48)
at org.ethereum.datasource.LevelDbDataSource.init(LevelDbDataSource.java:104)
at org.ethereum.datasource.LevelDbDataSource.makeDataSource(LevelDbDataSource.java:70)
at co.rsk.RskContext.buildTrieStore(RskContext.java:1031)
at co.rsk.RskContext.buildAbstractTrieStore(RskContext.java:951)
at co.rsk.RskContext.getTrieStore(RskContext.java:408)
at co.rsk.RskContext.buildRepositoryLocator(RskContext.java:1073)
at co.rsk.RskContext.getRepositoryLocator(RskContext.java:384)
at co.rsk.RskContext.getTransactionPool(RskContext.java:353)
at co.rsk.RskContext.buildInternalServices(RskContext.java:844)
at co.rsk.RskContext.buildNodeRunner(RskContext.java:836)
at co.rsk.RskContext.getNodeRunner(RskContext.java:302)
at co.rsk.Start.main(Start.java:34)
Looks like the most likely problem is an incompatibility of something within RSKj with my chip architecture.
Is there a workaround that will allow RSKj to run with an M1 chip?
You can try to use Rosetta to run x86 code on M1. Just add arch -x86_64 at the begin of your command.
arch -x86_64 java \
-classpath ~/.rsk/rskj-core-3.1.0-IRIS-all.jar \
-Drpc.providers.web.cors=\* \
-Drpc.providers.web.ws.enabled=true \
co.rsk.Start \
--regtest
You are right, the problem is with the leveldbjni dependency, which is not running on aarch64 architecture. However, one can get around this limitation by running RSK node in a Docker container.
This process is described in detail in the Docker installation instructions on the RSK devportal.
Summary:
You can install Docker running
brew install --cask docker
Register a free Docker account, login to your installed desktop app and then in the terminal run
docker run rsksmart/rskj-standalone
Then you should download Dockerfile.RegTest and supervisord.conf from artifacts repo and in the same folder execute:
docker buildx build --platform linux/amd64 -t regtest -f Dockerfile.RegTest .
When the build finishes, you have a container ready to run RSK. To run the container, you should execute
docker run -d --name regtest-node-01 -p 4444:4444 -p 30305:30305 regtest
Now your local test RSK node will be running ready for testing your smart contracts.
I know that is possible to use && (and) statement to go running multiple commands for a same alias. However for long combinations it loses in readability. For example:
save = !git status && git add -A && git commit -m \"$1\" && git push --force && git log && :
Is there a multi-line way to write it?
Maybe wrapping it with {} for example?
You can use a line escape (\) to break lines like this:
[alias]
save = !git status \
&& git add -A \
&& git commit -m \"$1\" \
&& git push -f \
&& git log -1 \
&& : # Used to distinguish last command from arguments
You can also put multiple statements inside a function like this:
[alias]
save = "!f() { \
git status; \
git add -A; \
git commit -m "$1"; \
git push -f; \
git log -1; \
}; \
f; \
unset f"
See Also: Git Alias - Multiple Commands and Parameters
I'd refrain from writing such extensive aliases in the config file. You can also add new commands by adding an executable file named git-newcommand to your PATH. This could be a Bash script, Python script or even a binary as long as it's executable and named with the prefix "git-".
In case of scripts you've to add the proper Hashbang:
#!/usr/bin/env python
Export the PATH, for example in your home:
export PATH="${PATH}:${HOME}/bin"
This is more modular, portable and easier debuggable.
After compiling openldap-2.4.33 on Centos 6.3 with the following options, I am unable to understand what this error is telling me:
Server was installed as a 'minimal' install, with the following addons:
yum install ntp autofs gcc make perl strace nmap tree rpm-build rpm-devel rpmdevtools rpm-libs rpm-python \
openssl openssl-devel perl-CPAN libtool libtool-ltdl-devel.x86_64 libtool-ltdl.x86_64 \
db4.x86_64 nss_db.x86_64 compat-db.x86_64 db4-devel.x86_64 \
tcp_wrappers.x86_64 tcp_wrappers-devel.x86_64 tcp_wrappers-libs.x86_64 \
unixODBC unixODBC-devel mysql-devel cyrus-sasl-devel.x86_64 perl-ExtUtils-Embed.x86_64 \
-y
After basic installation of the server as a VM on ESX, I ran the following ./configure to compile and install :
export CPPFLAGS="-I /usr/lib64/perl5/CORE"
export LDFLAGS="-L/usr/lib64 -L/usr/lib64/perl5/CORE"
export PERL_CPPFLAGS="`perl -MExtUtils::Embed -e ccopts -I/usr/lib64/perl5/CORE`"
ldconfig
./configure \
--prefix=/ \
--enable-shared --enable-debug --enable-dynamic --enable-syslog --enable-proctitle --enable-ipv6 \
--enable-local --enable-slapd --enable-cleartext --enable-crypt --enable-lmpasswd --enable-spasswd \
--enable-modules --enable-rewrite --enable-rlookups --enable-slapi --enable-slp --enable-wrappers \
--enable-backends --enable-bdb --enable-dnssrv --enable-hdb --enable-ldap --enable-mdb \
--enable-meta --enable-monitor --enable-null --enable-passwd --enable-perl --enable-relay \
--enable-shell --enable-sock --enable-sql --enable-overlays --enable-accesslog --enable-auditlog \
--enable-collect --enable-constraint --enable-dds --enable-deref --enable-dyngroup --enable-dynlist \
--enable-memberof --enable-ppolicy --enable-proxycache --enable-refint --enable-retcode --enable-rwm \
--enable-seqmod --enable-sssvlv --enable-syncprov --enable-translucent --enable-unique --enable-valsort \
--enable-perl --disable-ndb --with-cyrus-sasl --with-threads --with-tls --with-yielding-select \
--with-mp
I've taken the basic slapd.conf and only added my own dn.
When I run slaptest this is what I get:
slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d/
5125cefd register_matching_rule: could not locate associated matching rule generalizedTimeMatch for ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
slap_schema_init: Error registering matching rule ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
5125cefd slaptest: slap_schema_init failed
The only schema with some kind of clue is ppolicy.schema, but I'm at a loss as to what to do.
Those matching rules are internal, both are defined in OpenLDAP's servers/slapd/schema_init.c with no conditionals.
generalizedTimeMatch is defined first, and then generalizedTimeOrderingMatch, which refers to generalizedTimeMatch in its "associated" matching rule. The error originates in servers/slapd/mr.c as the matching rules are added.
The matching rules are built in an array of struct slap_mrule_defs_rec, and iterated over in order. There's no obvious way for that to fail.
Your list of options and overlays is quite, um, complete.
There is a chance that there's some incompatibility or dependency problem with the overlays, but I don't see it (several overlays add to the schema and use those matching rules as a side-effect of some attributes: dds, ppolicy, accesslog; as does the monitor backend).
My best guess is that there is some compile problem, possibly arising from compiler options, either optimisation/alignment and/or some stale .o file, but I'm guessing here. You don't include your actual make and install steps, there's a similarly slim chance that you have some conflict arising from an incomplete installation, or previous installation (old binaries or schema files).
I'd suggest:
make clean
make depend && make && make test
and see what happens (make test will take quite some time). It that works, then you might consider installing to /usr/local to avoid conflicting files. If that doesn't work then try a simple configure with minimal options:
./configure --with-threads --with-tls
and then add in just the modules and backend(s) you need.