On Jan 23, 2008 7:17 PM, Bobby Krupczak <[EMAIL PROTECTED]> wrote: > > Hi! > > > > Static linking does not seem appropriate as I cant get my app to > > > statically link against libssl/libcrypto (I get lots of undefined > > > symbol errors) and statically linking tends to not work well across > > > platforms that have different versions of underlying libraries. > > > > > > > That seems strange, why would linking against libssl.a/libcrypto.a > > give problems? What unresolved symbols do you get? You could still > > link dynamically against system libraries while using > > libssl.a/libcrypto.a (atleast i think so). > > I havent figured out how to switch between static linking for > libssl.a/libcrypto.a and dynamically linking the rest. If I link with > -static, it links the whole thing statically and I havent figured out > how to re-enable it.
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. > I am working on munging the makefiles to remove the soname from the > library build. Then, the linker simply looks for filename matches > rather than soname matches. > > Thanks, > > > Bobby -jb ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
