> -----Original Message-----
> From: owner-openssl-dev@openssl.org
> [mailtowner-openssl-dev@openssl.org]On Behalf Of Zhao, Wenzhong, Dr
> {Zhao}(GSFC-613.2)[SSAI]
> Sent: Monday, March 03, 2008 7:52 PM
> To: openssl-dev@openssl.org
> Cc: Wenzhong.Zhao@nasa.gov
> Subject: Install openssl-0.9.8g on a Mac OS X PPC server
> Hi,
> My question is:
> How can I generate a loadable library module libssl.so of openssl-0.9.8g
> on a Mac OS X 10.4.11 PPC server?
> I need to install openssl-0.9.8g on a Mac OS X 10.4.11 PPC server. This
> update is required for web server apache-1.3.33.
> I used the following commands to compile and install:
> Configure shared darwin-ppc-cc
> make
> make test
> make install
> All these commands successfully finished. However, I got libssl.a and
> libssl.dylib

That's what your supposed to get.

> but did not get libssl.so. I made a symbolic link from
> libssl.dylib to libssl.so.

That will not work.

> Unfortunately, apache web server daemon
> could not start if loading libssl.dylib is specified. How can I fix
> this problem?

For starters, MacOS X uses .dylib as it's shared library extension,
it does not use .so as the shared library extension. The runtime
linker looks for libssl.dylib, not libssl.so.

The biggest problems with compiling shared libraries on MacOS X,
frankly, is dealing with Borgified makefiles and hacked-up
configure scripts that insist on spitting out .so libraries
under MacOS X. OpenSSL is doing the right thing, you are not.

There is one other twist to using shared libraries under MacOS X
and that has to do with locating them. With most unixes, you
dictate shared library location in 1 of two ways. You either use
the -R directive during the link phase of the final executable
to pass a runtime link path to the executable, or you modify
a configuration file that the runtime linker looks at to find
paths of all the locations it's supposed to look for dynamic

With MacOS X up to 10.4, what you do is you brand the name of
where the dynamic library will be located into the dynamic library
itself during link phase - that is, either a complete path
including library name, or a path including library name relative
to where the executable is. There is none of this nonsense of
passing search paths, the runtime linker does not have the
ability to search paths for libraries. During the link phase
of the executable, the linker takes the full pathname from
each library that is linked in, and puts it into the executable.

With MacOS X 10.5, they finally came into the modern age and
allow you to pass a search path to the executable.

Frankly, you need to look into the Fink project, it sounds like
you do not have enough experience porting software on MacOS X
to be able to make a successful port here - you really should
start your porting efforts on MacOS X with something a lot
smaller and simpler than OpenSSL. Very
few open source projects out there have makefiles that understand
MacOS X, particularly the older versions. There are compiler
options that are missing in the gcc supplied from Apple that
you use special techniques to work around. It can become rather
tideous at times, and when I'm doing a quick testing project I
will often dispense with dynalibs and compile everything static
just to make sure it is going to work first.

This of course sets aside all of the issues with the PPC architecture
which is big-endian, and the intel architecture that's little-endian.

And there is also the issue with you can create a universal binary
that runs on both PPC and intel.

The fink project has most of these packages precompiled anyway so
you don't have to bother building them. See http://www.finkproject.org/
They even have openssl, although it's older.

If you must build it, at least see how they built the 0.9.7



__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org