> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Zhao, Wenzhong, Dr > {Zhao}(GSFC-613.2)[SSAI] > Sent: Monday, March 03, 2008 7:52 PM > To: openssl-dev@openssl.org > Cc: [EMAIL PROTECTED] > 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 libraries. 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 package: http://pdb.finkproject.org/pdb/package.php/openssl097 Ted ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
