>>(2) >>after install, note: >> >> >>for v0.9.8a: >>otool -L libssl.dylib: >> libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) >> libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version >> 0.9.8) >> /usr/local/lib/libgmp.3.dylib (compatibility version 7.0.0, current >>version 7.3.0) >> /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version >>1.0.0) >> /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version >>92.0.0) >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current >>version 88.0.0) >> >> >>v098x builds, for whatever reason, are MISSING the "/usr/local/ssl/lib" >>install_name prefixes to the libssl/libcrypto libs. >> >>this causes all SORTS of downstream probs ... > > > If you want better response time be more specific describing problems. > Even if appears selfobvious to you. Point is that without [daily] access > to MacOS X and massive hands-on experiense "all SORTS" have very little > [if any] meaning. Describe at least one problem in more "tangible" > terms. Check tomorrow snapshots as they become available. The case is > being dismissed.
Well, above was poorly worded. Let me rephrase. 1. The problem is [beleived to be] fixed now. Download and verify a snapshot from ftp://ftp.openssl.org/snapshots/. 2. For better response time *next time* be more specific describing problem. Keep in mind that some targets are community supported. This means that if support for some target was originally submitted by a list subscriber and later related problem report contains any sign of platform-specific lingo, which is not directly recognized by the team, then we kind of expect other [ideally original] subscribers to audit the suggestion and speak in its favor or suggest better solution. The way around it is to get rid of lingo, avoid expressions like "go slap them," etc., but instead describe the problem in "tangible" terms [like application fails to start with this message], present system call traces, quote manual page, refer to on-line documentation, in other words whatever it takes for a person without daily hands-on experience on given platfrom to *judge* the problem and recognize the proposed solution as appropriate. > the problem is that applications i'm attempting to link to openssl 0.9.8 -- > without these > install_name prefixes -- either (a) do not 'find' the lib, despite an > LDFLAGS/CPPFLAGS > specification, or (b) incorrectly select the Apple-bundled libs on /usr. Can you elaborate on (b)? Can you actually confirm that MacOS X application dynamically linked with 0.9.8 can at run-time end up linked with Apple-bundled 0.9<=8 dylib? If yes, can you speculate on or figure out and tell how it happens? This has everything to do with "Shared library version numbers" thread on <openssl-dev>, where I mention that it's believed that it can't take place om MacOS X [because OpenSSL encodes full version number into MacOS X analog of DT_SONAME field]. A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
