On Wed, Feb 22, 2012 at 9:12 AM, Mladen Turk <mt...@apache.org> wrote:
> On 02/22/2012 05:47 PM, Costin Manolache wrote: > >> On Wed, Feb 22, 2012 at 8:13 AM, Mladen Turk<mt...@apache.org> wrote: >> >> One thing I would appreciate help with: I would like to have an option to >> statically link >> openssl and apr into the tc-native .so - I mean use openssl.a, apr.a. >> >> > You mean for unixes? > The solution would be to create stub libssl.so and libcrypto.so > so that libtcnative don't carry their SONAME and link to system so.x... > > Static linkage is not a good idea I'm afraid. > > > The reason is to avoid the system libraries which will probably have the >> wrong version. >> >> > Right. Having stubs, libtcnative will always link to libssl.so which > is usually symlink on any system. > At runtime we can check for SSL_version and fail in case it has wrong ABI. > > However, not sure why you wish to do that. Many distros already provide > tomcat-native so there's no real point for doing that, especially since > we should not distribute unix binaries. > Yes, distros provide tomcat-native, apr and openssl - with the 'stable' releases. I'm trying to provide a way for people to build "libtcnative-2.so" so it can be installed on those systems along with the existing apr, openssl and libtcnative-1, without requiring the installation of 2 versions of openssl, apr. It seems to work for me on linux ( using cmake ) - I get a tcnative.so with all the openssl/apr code linked in, without dependencies to libapr.so ( no SONAME ). So basically someone ( distros, users ) could build and deploy the new library along with the stable ones. I don't think we can require to upgrade the platform openssl or apr. The alternative would be to have the new openssl/apr .so in some /usr/local/ location. Costin > > > Regards. > > -- > ^TM > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@tomcat.apache.**org<dev-unsubscr...@tomcat.apache.org> > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
