On Jan 25, 2008 1:29 PM, Jimmy B <[EMAIL PROTECTED]> wrote: > 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. >
Duh! typo. I meant 'should not' cause problems. :) -jb ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
