Hi! > Well I remember that (at least gcc/ld) first .so are searched and then .a for > a given -l<name>. So if you only have libssl.a/libcrypto.a in the path then > it should work. > > OR > > You could directly give libssl.a/libcrypto.a in the link command (not > -lssl, -lcrypto). > > > > > Also, since the libs are compiled on one platform and then the app is > > often moved to different systems, statically linking the library to > > external symbols could cause problems. > > > > But I guess just having the openssl stuff statically built-in should > cause problems. > Let me know if you try this.
Thanks for the reply. Avoiding static linking is best but linking directly with the .a will work. However, what I got working (finally) was the following: + junk gcc for Solaris/x86 and use the free Sun Studio 12 to compile/build openssl 0.8.9g + re-compile everything (all platforms) removing the soname directive from Makefile.shared + re-link and remove the SHLIBDEPS from the link line for libssl in Makefile What I ended up with is the ability to rename libssl.so and libcrypto.so to something platform specific and the ability to load them at load-time w/o naming conflicts. I dont know if this is something useful to other users so it may not be worth trying to roll this into the configure process. Thanks for all the suggestions! Bobby ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
