July 2005 - Darwin-dev - lists.apple.com

Re: any insights? upgrade from OpenSSL v0.9.7 --> 0.9.8 changes linking behavior on OSX
by OpenMacNews 19 Jul '05

19 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com hi, % gcc --version powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 (Apple Computer, Inc. build 5026) for VERSION 0.9.7g: ./Configure \ --prefix=/usr/local/ssl097g \ --openssldir=/usr/local/ssl097g \ darwin-ppc-cc \ -DUSE_TOD \ threads \ shared \ no-idea make make depend make install results in: while, for VERSION 0.9.8: ./Configure \ --prefix=/usr/local/ssl098 \ --openssldir=/usr/local/ssl098 \ darwin-ppc-cc \ -DUSE_TOD \ threads \ shared \ no-idea make make depend make install results in: cheers, richard _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… well for comparison's sake, two versions of openssl (0.9.7g/0.9.8) built on the same box: % uname -a Darwin devbox 8.2.0 Darwin Kernel Version 8.2.0: Fri Jun 24 17:46:54 PDT 2005; root:xnu-792.2.4.obj~3/RELEASE_PPC Power Macintosh powerpc otool -L /usr/local/ssl097/lib/libssl.0.9.7.dylib /usr/local/ssl097g/lib/libssl.0.9.7.dylib (compatibility version 0.9.0, current version 0.9.7) /usr/local/ssl097g/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.0, current version 0.9.7) /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) otool -L /usr/local/ssl098/lib/libssl.0.9.8.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/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) again, NOTE the missing "/usr/local/ssl09*/lib" prepending the libssl/libcrypto components for v0.9.8. so, there's a difference ... but not clear (yet) whether it's due to OpenSSL or Apple's build system. again, openssl dev sez it's Mac -- but no details/reason :-( This email sent to site_archiver(a)lists.apple.com

1 0

Re: any insights? upgrade from OpenSSL v0.9.7 --> 0.9.8 changes linking behavior on OSX
by OpenMacNews 19 Jul '05

19 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com hi andrew, > i'll try _another_ clean rebuild ... tho, several to date have resulted in the > same problem ... any OTHER witty questions? hmmm? ;-D > > I bet the install names are wrong > > suggestions as to what/where in the openssl source to check for any > mis-assignments of the install names? i thought -- perhaps naiively -- that > libtool takes care of these .... it is. i always do, and i did. My understanding of what's happening is that MacOSX libs embed the path to their installation location inside themselves. Then when something links against it, it uses this embedded path to later find the library when its run. This works sort of like "-Wl,-rpath=/some/path" does on ELF toolchains, but its pretty weird to people used to the ELF toolchains on linux/solaris/*BSD. Your problem seems to be that the openssl installation must not be setting this path, or is only setting it to libname, rather than $prefix/lib/libname. I beleive the argument to gcc which sets this is --install_name. I'm not sure what libtool calls it. well, "--install_name" looks like a good place to start. google is my friend =) As a workaround, you could try setting DYLD_LIBRARY_PATH to /usr/local/lib. it's SUPPOSED to include it as a default if/when UNset ... but worth a try ... i'll report back with any progress, or lack thereof. thx again. richard _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… So why would you expect another one to help? ;) varying alignment of the sun, moon & stars ... random chance ... having been trained by my wife to simply do what i'm told without question ... If openssl is GNU configure based try explicitly specifying --prefix=/usr/local to configure. at the moment, i'm building both v0.9.7 & v0.9.8 into their own prefixes for a comparison ... This email sent to site_archiver(a)lists.apple.com

1 0

Re: any insights? upgrade from OpenSSL v0.9.7 --> 0.9.8 changes linking behavior on OSX
by Andrew Gallatin 19 Jul '05

19 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com OpenMacNews writes: > > i'll try _another_ clean rebuild ... tho, several to date have resulted in the > same problem ... So why would you expect another one to help? ;) > > I bet the install names are wrong > > suggestions as to what/where in the openssl source to check for any > mis-assignments of the install names? i thought -- perhaps naiively -- that > libtool takes care of these .... If openssl is GNU configure based, try explicitly specifying --prefix=/usr/local to configure. My understanding of what's happening is that MacOSX libs embed the path to their installation location inside themselves. Then when something links against it, it uses this embedded path to later find the library when its run. This works sort of like "-Wl,-rpath=/some/path" does on ELF toolchains, but its pretty weird to people used to the ELF toolchains on linux/solaris/*BSD. Your problem seems to be that the openssl installation must not be setting this path, or is only setting it to libname, rather than $prefix/lib/libname. I beleive the argument to gcc which sets this is --install_name. I'm not sure what libtool calls it. As a workaround, you could try setting DYLD_LIBRARY_PATH to /usr/local/lib. Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: any insights? upgrade from OpenSSL v0.9.7 --> 0.9.8 changes linking behavior on OSX
by OpenMacNews 19 Jul '05

19 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com hi chris, thx for the reply =) FOR OPENSSL VERSION v0.9.8 % otool -L lynx ... 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) ... Do otool -L /usr/ local/libssl.0.9.8.dylib and I bet the install names are wrong. The install names should look like /usr/local/libssl.0.9.8.dylib, but I bet they are libssl.0.9.8.dylib. you're correct ... which presents the same as with all the other ssl-dependent apps ... cheers, richard _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… My guess is that you messed up your openssl install. entirely possible, though the install procedure for 0.9.7 & 0.9.8 was the same ... /usr/local/lib/libssl.0.9.8.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/libz.1.dylib (compatibility version 1.0.0, current version 1.2.2) /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) i'll try _another_ clean rebuild ... tho, several to date have resulted in the same problem ... I bet the install names are wrong suggestions as to what/where in the openssl source to check for any mis-assignments of the install names? i thought -- perhaps naiively -- that libtool takes care of these .... This email sent to site_archiver(a)lists.apple.com

1 0

Re: any insights? upgrade from OpenSSL v0.9.7 --> 0.9.8 changes linking behavior on OSX
by Chris Zubrzycki 19 Jul '05

19 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 19, 2005, at 10:28 AM, OpenMacNews wrote: hi all, i'm building on OSX 10.4.2. i've upgraded OpenSSL from v0.9.7 --> v0.9.8, built into /usr/local. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Darwin) Comment: Please sign reply-http://www.gnupg.org iEYEARECAAYFAkLdD/MACgkQ+/mCMqKrwHBSWwCfXOF7jqVlJAcUhjGp4+t4EYOQ sN0AnRWBSW5n2VzkQpEfZ71MNhuW49SG =LA90 -----END PGP SIGNATURE----- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… i, alas, seem to be getting no 'traction' on this anywhere else, so i'll try here too ... when i build an app against ssl libs, e.g., here: 'lynx' (results are the same for an/all other apps ...), 'otool -L' on the resultant binary shows: FOR OPENSSL VERSION v0.9.7 % otool -L lynx ... /usr/local/libssl.0.9.7.dylib (compatibility version 0.9.0, current version 0.9.7) /usr/local/libcrypto.0.9.7.dylib (compatibility version 0.9.0, current version 0.9.7) ... FOR OPENSSL VERSION v0.9.8 % otool -L lynx ... 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) ... My guess is that you messed up your openssl install. Do otool -L /usr/ local/libssl.0.9.8.dylib and I bet the install names are wrong. The install names should look like /usr/local/libssl.0.9.8.dylib, but I bet they are libssl.0.9.8.dylib. - -chris zubrzycki - - -- PGP public key: http://homepage.mac.com/beren/publickey.txt ID: 0xA2ABC070 Fprint: 26B0 BA6B A409 FA83 42B3 1688 FBF9 8232 A2AB C070 ======================================================== A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? This email sent to site_archiver(a)lists.apple.com

1 0

any insights? upgrade from OpenSSL v0.9.7 --> 0.9.8 changes linking behavior on OSX
by OpenMacNews 19 Jul '05

19 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com hi all, i'm building on OSX 10.4.2. i've upgraded OpenSSL from v0.9.7 --> v0.9.8, built into /usr/local. FOR OPENSSL VERSION v0.9.8 % otool -L lynx ... 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) ... QUESTION: why is this occuring? is this a problem? thx for any/all comments! cheers, richard _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… i, alas, seem to be getting no 'traction' on this anywhere else, so i'll try here too ... when i build an app against ssl libs, e.g., here: 'lynx' (results are the same for an/all other apps ...), 'otool -L' on the resultant binary shows: FOR OPENSSL VERSION v0.9.7 % otool -L lynx ... /usr/local/libssl.0.9.7.dylib (compatibility version 0.9.0, current version 0.9.7) /usr/local/libcrypto.0.9.7.dylib (compatibility version 0.9.0, current version 0.9.7) ... NOTE: the lack of a precedent path (/usr/local/) for the libssl*/libcrypto* link components in the latter case. the folks @ openssl suggest that this is NOT an openssl issue, rather a Mac one ... This email sent to site_archiver(a)lists.apple.com

1 0

NOTICE: anoncvs downtime
by Kevin Van Vechten 18 Jul '05

18 Jul '05

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com - Kevin _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… The anoncvs.opensource.apple.com server will be offline shortly after 13:00 PDT tomorrow, Tuesday 7/19/05, for a system upgrade. The upgrade is expected to take less than two hours. This email sent to site_archiver(a)lists.apple.com

1 0

Re: severe gcc problems
by Andrew Pinski 18 Jul '05

18 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com > > >>> g++ -c -o d_iDS_d_EX_delta.o -g -O3 d_iDS_d_EX_delta.c > >>> cc1plus(1322) malloc: *** vm_allocate(size=3888427008) failed > >>> (error code=3) > >> > >> This is failing because it is trying to allocate nearly 4GB of > >> memory. This will clearly fail in a 32 bit process like the > >> compiler. Whether this was caused by a compiler problem or > >> something in the code, there is not enough information to even guess. > > > > I don't know, the source code is just 221K but there's a horde of > > overloaded operators. 220,772 B vs 3.8G is almost 17,600 times > > difference! I never thought that compiler might ever need so much > > memory. > > Try building without -g. gcc is rather space-inefficient with debug > information, especially in some C++ code. You might also try -gfull > instead of -g, which works better in some cases. Actually GCC will take almost no more memory with -g than without it. The scheduler in GCC is known to take loads of memory. First try at -O1 and then at -O2. If those fail report a bug about memory usage being high. -- Pinski _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: severe gcc problems
by Greg Parker 18 Jul '05

18 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com g++ -c -o d_iDS_d_EX_delta.o -g -O3 d_iDS_d_EX_delta.c cc1plus(1322) malloc: *** vm_allocate(size=3888427008) failed (error code=3) This is failing because it is trying to allocate nearly 4GB of memory. This will clearly fail in a 32 bit process like the compiler. Whether this was caused by a compiler problem or something in the code, there is not enough information to even guess. I don't know, the source code is just 221K but there's a horde of overloaded operators. 220,772 B vs 3.8G is almost 17,600 times difference! I never thought that compiler might ever need so much memory. Try building without -g. gcc is rather space-inefficient with debug information, especially in some C++ code. You might also try -gfull instead of -g, which works better in some cases. -- Greg Parker gparker(a)apple.com Runtime Wrangler _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: severe gcc problems
by Tomas Zahradnicky 18 Jul '05

18 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com -O0 works normally and produces 4,196,736 B object file. Hmm, if I switch to -O0, it works and 54M libder.a gets properly archived. I'm however unable to use this archive because of tens of thousands of errors like this one: /usr/bin/ld: libder.a(d_iDS_d_EX_ld.o) relocation overflow for relocation entry 140066 in section (__TEXT,__text) (displacement too large) I've solved that by making few < 32M dylibs and it works now. Tomas -- # Ing. Tomas Zahradnicky, Jr. # The Czech Technical University # Dept of Computer Science, FEE-CTU Prague _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… g++ -c -o d_iDS_d_EX_delta.o -g -O3 d_iDS_d_EX_delta.c cc1plus(1322) malloc: *** vm_allocate(size=3888427008) failed (error code=3) This is failing because it is trying to allocate nearly 4GB of memory. This will clearly fail in a 32 bit process like the compiler. Whether this was caused by a compiler problem or something in the code, there is not enough information to even guess. I don't know, the source code is just 221K but there's a horde of overloaded operators. 220,772 B vs 3.8G is almost 17,600 times difference! I never thought that compiler might ever need so much memory. What systems does this code build on successfully? This email sent to site_archiver(a)lists.apple.com

1 0