Ahh I found the problem. It would be nice to have this fixed in the next release
of OpenSSL if any developers are reading this :-).
Apparently you need to add "-64" to the linker flags when building 64-bit libs
on Solaris. Unfortunately Sun Workshop 5.0 didnt seem to pass that flag
correctly to the linker, so this isn't just a simple matter of adding -64 to
LDFLAGS. This may work correcly with 6.0. I ended up calling the linker directly
to create the lib instead of calling it through cc and it seems to be working.
----[snip]----
According to sunsolve bugid: 4401698
Problem
-------
When creating a .so from a .a, ld is documented to use the "bitness" of the
first object it encounters as the "bitness" of the output.
If the only input encountered is .a, containing only 64-bit objects, then on
Solaris 7 the output file will be 32-bit, and empty.
On Solaris 8 the warning:
ld: warning: file libaxy.a(x.o): wrong ELF class: ELFCLASS64
.. is additionally given (as per bug 4219652).
This bug is to report/request that ld should not default to 32-bit when "fed"
such an archive.
Workaround
----------
Place a 64-bit .o on the ld command-line: either a dummy .o or one extracted
from (amd removed from) the .a archive.
Unpack the .a archive and include the .o's on the ld line: impossible if as in
the reporting customer you have literally thousands of objects in the archive.
michael.walker@Eng 2001-01-04
The recommended work-around/solution for this is to use the 'ld -64 ... lib.a'
option. The '-64' changes the default object being built to a 64bit object from
a 32bit object.
--
Jeff Layton
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
