[note: this patch has been Cc:'ed to [EMAIL PROTECTED] The patch itself
makes no changes or additions to any cryptographic routines. It changes
only the software build process for OpenSSL 0.9.6a, available from
http://www.openssl.org
]
[I'm not subscribed to openssl-dev, please Cc: me on any replies to this
message]
All-
I recently needed to build openssl for use with other software, so I started
looking at the build process for 0.9.6 and now 0.9.6a. I usually build
first on my desktop platform (alphaev56-dec-osf5.1) and then rollout to
other platforms.
I noticed a few minor issues and areas where improvements can be made. Some
of these were fixed with the 0.9.6a release, but a few remain. The patch
addresses some of them:
1) Tru64 was misspelled as True64 in several places in the documentation and
in a couple comments in the code. The patch updates all the places I could
find, to use the correct spelling.
2) The default Configure target, generated by config, was `alpha-cc', no
matter what version of the OS you were on. I added code to `config' such
that people on OSF/1 1.x - 3.2b, or Digital UNIX 3.2c - 3.2g (the name
changed when the OS was branded at rev 3.2c) get a new entry, `alphaold-cc',
which is just the previous `alpha-cc' entry. People on Digital UNIX 4.0 -
4.0e or Tru64 UNIX 4.0f - current (the name changed again when Compaq took
over and tried to get other hardware vendors to use their version of UNIX)
now get `alpha-cc', which is a copy of the old `alpha164-cc' entry. It
uses the newer `-fast' option to the compiler, to get the full complement
of optimizations available.
3) People on Digital/Tru64 4.x or 5.x, that get the alpha-cc target from
config, now also have the appropriate thread flag too. Adding
-pthread
to CFLAGS is all that's needed (it auto-defines -D_REENTRANT and automatically
links against the thread-safe version of any libraries, if available).
4) The shared library targets have changed just a bit. People that get
`alphaold-cc' now get a shared library target named alpha-osf1-shared, which
is exactly the same as the previous tru64-shared.
People that get `alpha-cc' or that choose `alpha164-cc' explicitly get
the shared library target `tru64-shared', which now contains one additional
flag, `-msym'. From the Tru64 ld man page:
<quote>
-msym
Produce an msym table for a dynamic executable or shared object. This
table contains additional dynamic symbol information. If an executable
or shared library is built without an msym table, the loader creates
one each time the executable or shared library is loaded. Use of the
-msym option causes the linker to create the msym table, thus reducing
load time and the amount of dynamic memory allocated by the loader.
Unlike the loader-generated msym tables, the linker produces msym
tables that are shared between processes.
</quote>
This option seems to have appeared in 4.x, so it's only appropriate if you're
using the newer compiler (i.e. you're on a recent release of the OS).
5) I've noted (but have not fixed) a problem with the shared library targets,
if one is building with rsaref. As a side note, the docs (esp INSTALL)
should say *why* someone would choose to do so, or why not. Is it generally
a win to build with RSADSI's RSA reference library, or not? A bit more
verbiage on the advantages or disadvantages of this option might be helpful
for the newcomer to openssl.
In any case, if you choose to build with rsaref and you're also building
shared libraries, your build will probably fail. When the shared libcrypto.so
is created, it's created like:
cc -shared -msym -no_archive -o libcrypto.so -set_version 0.9.6 -all libcrypto.a -none
-L. -lRSAglue -lrsaref -L/local/lib -lc
The problem is that there is no libRSAglue.so, and the `-no_archive' makes
it such that the existing libRSAglue.a can't be used. Perhaps libcrypto.so
needs to have a shared library dependency on libRSAglue.so, in the case
where rsaref support is asked for at config time?
Since all code on the alpha/Tru64 is position independent code (PIC), I'm
not sure why the `-no_archive' is even being specified. Why not let the
compiler choose whatever libraries are available?
Also, I understand why (in theory) you don't want to pull an entire copy
of both the libRSAglue and librsaref libraries into libcrypto, wouldn't it
(in this case) make good sense to do so? If you don't (i.e. you keep
the `-none' in front of those two libraries) you're requiring that both
libraries be installed, in shared library format, and that people that
link against libcrypto also must link against both of them.
6) I've added a Configure target `alpha-cc-rpath' (which will never be
selected by `config', the user has to select it manually) which is the
same as the `alpha-cc' target except that it uses `tru64-shared-rpath'
as the shared library target. This new shared library target builds
an RPATH into the shared libraries that are created.
This is a win on Tru64 (and would be on IRIX 6.x, too, since it works
almost exactly the same way) since any application that links against
those shared libraries will automatically pick up the RPATH. This means
that if you build your RPATHs into your shared libraries, you never
need to worry about building them into the applications themselves.
Hopefully you'll find some or all of this useful. Please let me know if
there are problems with my patch, or things that need to be reworked before
they can be accepted.
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
