On Fri, Jun 03, 2005 at 11:59:45AM +0200, Martin Costabel wrote:
>
> dyld: lazy symbol binding failed: Symbol not found: _EVP_idea_cbc
> Referenced from: /sw/lib/libssl.0.9.7.dylib
> Expected in: /usr/lib/libcrypto.0.9.7.dylib
>
> The problem is that Tiger's dyld happily searches
> /usr/lib/libcrypto.0.9.7.dylib when this is loaded instead of
> /sw/lib/libcrypto.0.9.7.dylib, although the latter is in the dependency
> list of /sw/lib/libssl.0.9.7.dylib.
>
> Loading /usr/lib/libcrypto.0.9.7.dylib happens whenever
> ApplicationsServices.framework is loaded, for example from Apple's
> /usr/X11R6/lib/libfreetype.6.dylib or, in the case of the gome libs,
> from libgdk-x11-2.0.dylib.
>
> Here is the example:
>
> % cat cryp.c
> #include <stdio.h>
> #include <openssl/ssl.h>
> int main()
> {
> printf("Program starts here\n===\n");
> SSL_library_init();
> printf("Finished successfully\n");
> }
>
> Now compile this once with
> gcc -o goodcryp cryp.c -I/sw/include -L/sw/lib -lssl
> and a second time with
> gcc -o badcryp -I/sw/include -framework ApplicationServices -L/sw/lib -lssl
> The first one runs OK, the second one gives the _EVP_idea_cbc error.
Is this just the first reported example of a more general class of
problems where both Fink and Apple supply a library that has several
constituent .dylibs? Say a program links to Fink's libfoo, which links
to Fink's libfoo-part2, and to Apple's libbar, which links to Apple's
libfoo, which links to Apple's libfoo-part2. If symbol names are
different between Apple's and Fink's versions of foo, dyld has a 50:50
chance of giving us a mismatched libfoo/libfoo-part2 pair. As to *why*
the same version of the same lib would have symbols with different
names...um...
> My conclusion is that if we want to maintain our own libssl.*.dylib, we
> need to link it *statically* against libcrypto. This is very easy, it is
> in fact already done for the binaries in the openssl097 package.
An interesting solution proposed by the R folks is to change the
install_name of the dylib. That way [wherever within the linkings of
ApplicationServices that has -lcrypto or its equivalent] and our
-lcrypto link to different .dylib filenames (as opposed to same
filename in different locations).
dan
--
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel
