Build OpenFHE without CMake

Library Questions
1

I am trying to create object files out of OpenFHE codes, so that multiple such object files might be linked later to give a final executable. This is not possible with the build instructions mentioned in OpenFHE, where cmake is to be used and which generates executable directly after ‘make’.

This is the Makefile I created to try to get use.o from my use.cpp source code, and then, ‘use’ executable is got from use.o (Code in use.cpp is same as simple-integers.cpp) -

INC_openfhe = -I/usr/local/include/openfhe -I$(IN)/usr/local/include/openfhe/cereal -I$(IN)/usr/local/include/openfhe/pke -I$(IN)/usr/local/include/openfhe/core
OPT_openfhe = -Dopenfhe_VERSION=1.0.2 -fopenmp

.PHONY:all
	
all: use

use.o:
	g++ -g $(INC_openfhe) $(OPT_openfhe) -c  use.cpp -o $@ 

use: use.o
	 g++ use.o -o use /usr/local/lib/libOPENFHEbinfhe.so.1.0.2 /usr/local/lib/libOPENFHEpke.so.1.0.2 /usr/local/lib/libOPENFHEcore.so.1.0.2

However, on running ‘make’, my ‘use.o’ is being created, but ‘use’ is not being created from use.o.
I am getting error, whose initial logs I am attaching in screenshot.

out_make
out_make1600×857 252 KB

Line 95 in use.cpp(pointed in the error log) is- cryptoContext->EvalMultKeyGen(keyPair.secretKey);

How do I build my OpenFHE object files and later create executable from them?

Note that when I create a similar Makefile for a use.cpp that has Palisade code, use.o and use are built without errors-

INC_PALISADE = -I/usr/local/include/palisade -I$(IN)/usr/local/include/palisade/cereal -I$(IN)/usr/local/include/palisade/pke -I$(IN)/usr/local/include/palisade/core
OPT_PALISADE = -DPALISADE_VERSION=1.11.7 -fopenmp

.PHONY:all
	
all: use

use.o:
	g++ -g $(INC_PALISADE) $(OPT_PALISADE) -c use.cpp -o use.o

use: use.o
	g++ use.o -o use /usr/local/lib/libPALISADEbinfhe.so.1.11.7 /usr/local/lib/libPALISADEpke.so.1.11.7 /usr/local/lib/libPALISADEcore.so.1.11.7
2

HI, the cmake system makes a few .so libraries during the build cycle. One can set a flag at the initial cmake definition to generate static or dynamic libraries as required. Is this not sufficient to build your executables either in dynamic or static linkage?

3

Yes, thanks, I checked that cmake can be used to create libraries which can later be linked to executable.
However, I am working with a code which I am trying to convert to HE domain using OpenFHE. It already has some Makefiles that are building files that I plan to convert to HE domain. So, is it possible to just modify this Makefile from something like (in case of Palisade, the below linking worked)-

$(EXE):$(BWA_LIB) $(SAFE_STR_LIB) src/main.o
	$(CXX) $(CXXFLAGS) $(LDFLAGS) src/main.o $(BWA_LIB) $(LIBS) -o $@

to something like-

$(EXE):$(BWA_LIB) $(SAFE_STR_LIB) src/main.o
	$(CXX) $(CXXFLAGS) $(LDFLAGS) src/main.o $(BWA_LIB) $(LIBS) -o $@ /usr/local/lib/libPALISADEbinfhe.so.1.11.7 /usr/local/lib/libPALISADEpke.so.1.11.7 /usr/local/lib/libPALISADEcore.so.1.11.7

Such a thing currently is giving error for OpenFHE, but works for Palisade.

4

The only advice I can give is examine the differences in where openfhe and palisade place their libraries and include files. other than some reorganization of where include files are placed and referenced in the source code, there is a 1:1 correspondence in the libraries between the two.

5

Is your issue addressed? I’d take dave’s advice to heart and slowly add complexity to your application. Overall I don’t know if we support this or have any insights, but if you find out how to do so please let us know and we can add an entry into our readthedocs

1 Like