I should mention that the obvious suggestion of "You need to link your framework against OpenSSL" is not what I'm looking for.
If I link my framework statically against OpenSSL, then I force the clients of my framework to use that static version of OpenSSL, which I don't want. If I link my framework dynamically against OpenSSL, then I force the clients of my framework to use the dynamic version of OpenSSL, which I also don't want. (correct me if I'm wrong on either of those points) -Patrick On May 15, 2010, at 11:29 PM, Patrick Rutkowski wrote: > I'm building a Framework which internally uses OpenSSL, and exposes a sort of > OpenSSL wrapper for various small purposes. > > However, when linking the framework, Xcode complains of missing symbols like: > > _ERR_error_string_n > _ERR_clear_error > _SSL_CTX_free > _SSL_CTX_new > _ERR_get_error > _SSL_library_init > _SSL_load_error_strings > > I'm puzzled about this, since my previous experience with dynamic libraries > has been with libtool projects via autotools, which such things never > happened. > > It turns out that libtool+autotools projects pass "-undefined dynamic_lookup" > to the linker, which leaves such undefined symbols to be resolved by the > client project. Which I assume it can resolve either by statically linking to > the ssl, or by dynamically linking to the ssl library. > > Is there any reason to NOT pass "-undefined dynamic_lookup" to the linker for > a framework project? I'm awfully tempted to do so. > > -Patrick > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
