> I've just built openssl-0.9.4 on Solaris with shared libraries and used
> these .so's with my JAVA application. All you need is to follow the
> procedures below:
>
> open static libraries (libssl.a, libcrypto.a) with ar -x command and obtain
> the object files.
> reassamble these files by using the gcc compiler with the -G option and
> obtain .so files.
??? I used to believe that this (run-time linking of none position
independent code objects) doesn't work at all, but I just did an
experiment and it apparently does work, i.e. a test program doesn't
crash and even produces meaningful result. *HOWEVER*! I would *not* call
it "with shared libraries" ever. Throwing the none-PIC objects into an
.so library effectively passes the whole link phase to the run-time
linker. Instead of just fixing up few entries in so called Global Offset
Table and procedure dispatch table the run-time linker all of a sudden
faces the challenge of resolving *all* references to *all* symbols which
results in substantial delaaayyyyy at start-up time. Secondly as it
fixes up the resolved references it promotes (or whatever) practically
all the code pages (which also takes time) to private ones thus killing
the very idea behind shared library model. As the code ceases to be
shared it also results in excessive memory consumption when a lot of
instances of the program in question are executed (even in comparison
with statically linked case when the code is still shared between
multiple instances).
>
> I don't know if I'm doing something wrong, but this way of obtaining .so's
> satisfies my needs.
Right, who cares how fast java application starts or how much memory it
consumes:-)
>
> Michael Sierchio wrote:
>
> > Has anyone successfully built openssl-0.9.4 on Solaris with shared
> > libraries?
But why??? Shared libraries are good for following reasons:
- possibility to upgrade/patch without relinking the existing
applications. but we can't guarantee binary compatibility as there is a
bunch of macros in header files providing access to private openssl
structures. so that you have to relink anyway.
- minimize footprint (both on disk and in memory) of applications
"community." but how large is the "community"? 1-2-3-4 applications and
you save what? (n-1)*2MB. is it really a problem?
- ship dynamically linked application to overseas "customer" and expect
him to fix corresponding .so library. why not ship myapp.a and have
customer to 'ld myapp.a -lssl -lcrypto' instead? you have to *demand*
he's using very same openssl version in either case (see above), but no
hassles with nobody-knows-for-sure compile procedure, .so versions,
run-time library path, etc.
- load 'em dynamically with LD_PRELOAD or dlopen(). that's the *only*
one left with no alternatives...
> > Any pointers greatly appreciated.
'./config -KPIC; make DIRS="crypto ssl"' to start with. At this point
you get libcrypto.a and libssl.a stuffed with PIC modules and can apply
Basar's trick, namely 'mkdir tmp; (cd tmp; ar x ../libssl.a); ld -G -o
libssl.so tmp/*; rm -rf tmp', then same to libcrypto.a. Finally 'make
clean; ./config; make' and you should be set. Note that it's just a
skeleton of a real procedure and I haven't tried it myself. You have to
think over .so version numbering, runtime pathes and other details
yourself:-)
Andy.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
