Re: Framework linking errors
Re: Framework linking errors
- Subject: Re: Framework linking errors
- From: Patrick Rutkowski <email@hidden>
- Date: Sun, 16 May 2010 00:00:20 -0400
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 (email@hidden)
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:
This email sent to email@hidden