Wow, you guys are good! Thanks.
-----Original Message----- From: Michael S. Zick <open...@morethan.org> To: openssl-users <openssl-users@openssl.org> Sent: Wed, Jul 20, 2011 9:27 am Subject: Re: Fwd: Trying to Link Statically to Libcrypto On Wed July 20 2011, brandon...@aol.com wrote: It didn't fix it. In the end, I cannot link statically without libsasl2.a, hich I am having difficulty obtaining, but which must be somehow obtainable. n the meantime, I am including libraries for which I have a static version in y objective files list, rather than as linker flags. I am still not able to ink in some libraries statically and others dynamically with -libraryname, nless I hide library names or something. The -dynamic flag doesn't work, nor o Bdynamic and Bstatic, which are really ld, not gcc, options. Even when I had included everything except lsasl2 and one other minor library mong my objctives, I was still getting problems on some very old Linux nstallations that it couldn't find references to the right GLIBCXX (whatever hat is) in my c and c++ libraries. I succeded in including libstdc++.a in my bject file list, but when I tried to include glibc.a, it broke the application. n googling around, I saw some posts that said that even if I could include the ompiler libraries in my code, it would make them less portable, not more ortable, because the runtime environment changes almost with every release. hat leaves me with telling users that they must update gcc and gcc-c++, not ompletely unreasonable, perhaps. Close only counts in horseshoes and 'nuke weapons, not in C++ source code. our clients do not need to update their gcc toolchain, in fact, they o not need it at all. hey only need the proper system libstdc++ version libraries installed. Some distributions install both. Sometimes as default, sometimes as an OS ption.) There are two major libstdc++ version libraries in use in the world. our choices when leaving libstdc++ as dynamic references: Build against version 5 and tell users of newer version 6 to install the ompatibility libstdc++ library. Build against version 6 and tell users of older version 5 to update/upgrade heir OS distribution. Build two versions, one against version 5 and one against version 6 - hip as appropriate to the client's OS age. Note: You can link libstdc++ static, leaving others of your choice dynamic. here is a gcc link option for doing just exactly that. ttp://gcc.gnu.org/onlinedocs/gcc/Link-Options.html This is __the wrong mailing list__ for learning Linux/C++/gnu toolchain usage. Mike Although my current orders are to make a portable executable, I think that I ay recommend that we use the "configure->make->make install" or "rpm/deb" echnique instead. I don't know how to write those and would have to learn. Brandon -----Original Message----- From: Amol Tambe <amolta...@gmail.com> To: brandonshw <brandon...@aol.com> Sent: Wed, Jul 20, 2011 3:35 am Subject: Re: Trying to Link Statically to Libcrypto Good to know all your problems were solved. What fixed the last one? Mind sharing the last link line that worked? It will even be worth posting that on the OpelSSL list so that others know in uture if needed. On Tue, Jul 19, 2011 at 11:32 PM, <brandon...@aol.com> wrote: It sounds great, but oddly, this is what happened: [root@linux Release]# ls -l /usr/lib/libsasl* lrwxrwxrwx. 1 root root 18 2011-07-08 18:35 /usr/lib/libsasl2.so -> ibsasl2.so.2.0.22 lrwxrwxrwx. 1 root root 18 2011-07-08 13:35 /usr/lib/libsasl2.so.2 -> ibsasl2.so.2.0.22 -rwxr-xr-x. 1 root root 98628 2009-02-24 05:44 /usr/lib/libsasl2.so.2.0.22 [root@linux Release]# [root@linux Release]# g++ -o"<my executable name>" <my object files> -static lcrypto -lldap -lxml2 -llber -lz -ldl -lm -lssl -dynamic -lsasl2 /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../libcrypto.a(fips.o): In function FIPSCHECK_verify': (.text+0xafb): warning: Using 'dlopen' in statically linked applications equires at runtime the shared libraries from the glibc version used for linking /usr/bin/ld: cannot find -lsasl2 collect2: ld returned 1 exit status [root@linux Release]# When I do not use the static keyword, it finds it. It is as though it didn't ee the dynamic flag. -----Original Message----- From: Amol Tambe <amolta...@gmail.com> To: brandonshw <brandon...@aol.com> Sent: Tue, Jul 19, 2011 12:19 pm Subject: Re: Trying to Link Statically to Libcrypto Good to hear that. Try this to get one step further g++ -o"<My exe name>" <my object file list> -static -lcrypto -lldap -lxml2 llber -lz -ldl -lm -lssl -dynamic -lsasl2 On Tue, Jul 19, 2011 at 9:21 PM, <brandon...@aol.com> wrote: Well, not too bad. This is what I get: /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../libcrypto.a(fips.o): In function FIPSCHECK_verify': (.text+0xafb): warning: Using 'dlopen' in statically linked applications equires at runtime the shared libraries from the glibc version used for linking /usr/bin/ld: cannot find -lsasl2 collect2: ld returned 1 exit status and I actually don't have a static version of libsasl yet, so that error is nderstandable. I wish I had a better mental model of what the principles here re. People seem to have told me that any library listed must be followed by very library it calls. I suppose with tools like ldd or nm, I could work this ut, but it doesn't seem very simple. I wish that there were some kind or ulti-pass linker so that order was irrelevant. Anyway, thank you. Brandon -----Original Message----- From: Amol Tambe <amolta...@gmail.com> To: brandonshw <brandon...@aol.com> Sent: Tue, Jul 19, 2011 11:03 am Subject: Re: Trying to Link Statically to Libcrypto Ahh ha... now I get your problem. Change this : g++ -o"<My exe name>" <my object file list> /usr/lib/libcrypto.a usr/lib/libldap.a /usr/lib/libxml2.a /usr/lib/liblber.a /usr/lib/libssl.a -lz ldl -lm -lsasl2 2>&1 To : g++ -o"<My exe name>" <my object file list> -static -lcrypto -lldap -lxml2 llber -lz -ldl -lm -lsasl2 -lssl If you get some errors, try changing the sequence of libs. _____________________________________________________________________ penSSL Project http://www.openssl.org ser Support Mailing List openssl-users@openssl.org utomated List Manager majord...@openssl.org
