[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: How to make an app using sfl smaller?


We do build MS Windows static biulds of all libraries (except the Free3
CTIL) for the PCT projects; it includes a static version of the Fortezza
CTIL.  This was done for exactly the same reason you want static libraries
for: reduction of DLLs/.so's.  There does happen to be a reason for these
DLLs (or .so's in your case).  For the SNACC workspace, you want to use the
"cppasn1_static" libraries (these are built as part of the BuildAll in
Windows).  On Linux, the SNACC C++ run-time library (.a) should be produced
along with the .so file.  This .a file should be distributed to the same
./SMPDist/util/VDASnacc/cpplib/lib directory as the.so file.   You will have
to delete the .so file to force linkage to the .a file.

For the SFL you will have to make libcert static:

	cd SMIME/libcert
	make -f Makelibcert LIBRARY

You will have to distribute this file youself to the SMPDist directory if
you follow our convention.

For the Free3 CTIL, you will have to update the image to link directly to
the .a file, or delete the .so from the SMPDist/sfl/libcert/lib directory
(which is probably easier, perhaps through a shell?  SAME for the SNACC
.so.).  Unfortunately we have never had callto build a .a file for the Free3
CTIL, so you will have to add a rule, something like:

	linkPKCS12: PKCS12ObjsCompile $(OBJS) sm_cms.o
        $(AR) rv ../../lib/libsm_free3DLL.a $(OBJS) sm_cms.o
	##RWC You will have to add these to you application. $(LIBS)

This is the same objects as dynmiclinkPKCS1q2 (I assume you want PKCS12,
which could probably be trimmed as well) except for the removal of "LFLAG1"
which defines the shared object build.

You should be aware that if you attempt to link 2 CTILs into the same
application, you will have to compile the CTIL sources with a define that
disables certain function names (used by the shared object logic to load the
virtual pointers to the classes).  Most user's never face this issue since
they link only 1 CTIL.

Once you establish a satisfactory set of changes for your makefile(s), if
you wish to have us maintain these changes (under a separate make rule, not
the default), we can incorporate these changes into the baseline.  In
addition, I can update the make and distribution shells to deliver both
types for SNACC, libcert and sm_free3 (.a and .so) to the distribution
directory, then add a special SMIME/Makefile rule to delete the .so versions
from SMPDist and re-make certain applications (e.g.
./SMIME/testsrc/hilevel/autoHi, our main test program).  This should
simplify your build procedures, especially considering we are preparing a
major release with many changes soon.

Bob Colestock

-----Original Message-----
From: Darryl Green [mailto:green@xxxxxxxxxxx]
Sent: Thursday, August 30, 2001 10:20 PM
To: IMC SMIME Free Library List (E-mail)
Subject: How to make an app using sfl smaller?

We are trying to get our application using SFL onto an embedded linux
platform. The standard build causes problems with the sheer number of very
general purpose shared libraries generated/used. While we can get the
application proper to statically link, and this helps, the free3 ctil has
many of the same dependencies. Is is possible to statically link the CTIL
rather than dynamically loading it?
Our only other alternative is to try to prune the libraries so that they
contain only the objects that are actually referenced. This is a non-trivial
process to do manually. Does anyone know of a utility that will do this?
Any other suggestions (other than more Flash...)?

Darryl Green
Project Manager, Realtime Systems
TAB Queensland Limited