On Wed July 20 2011, brandon...@aol.com wrote: > > It didn't fix it. In the end, I cannot link statically without libsasl2.a, > which I am having difficulty obtaining, but which must be somehow obtainable. > In the meantime, I am including libraries for which I have a static version > in my objective files list, rather than as linker flags. I am still not able > to link in some libraries statically and others dynamically with > -libraryname, unless I hide library names or something. The -dynamic flag > doesn't work, nor to Bdynamic and Bstatic, which are really ld, not gcc, > options. > > Even when I had included everything except lsasl2 and one other minor library > among my objctives, I was still getting problems on some very old Linux > installations that it couldn't find references to the right GLIBCXX (whatever > that is) in my c and c++ libraries. I succeded in including libstdc++.a in > my object file list, but when I tried to include glibc.a, it broke the > application. In googling around, I saw some posts that said that even if I > could include the compiler libraries in my code, it would make them less > portable, not more portable, because the runtime environment changes almost > with every release. That leaves me with telling users that they must update > gcc and gcc-c++, not completely unreasonable, perhaps. >
Close only counts in horseshoes and 'nuke weapons, not in C++ source code. Your clients do not need to update their gcc toolchain, in fact, they do not need it at all. They only need the proper system libstdc++ version libraries installed. (Some distributions install both. Sometimes as default, sometimes as an OS option.) There are two major libstdc++ version libraries in use in the world. Your choices when leaving libstdc++ as dynamic references: Build against version 5 and tell users of newer version 6 to install the compatibility libstdc++ library. Build against version 6 and tell users of older version 5 to update/upgrade their OS distribution. Build two versions, one against version 5 and one against version 6 - ship as appropriate to the client's OS age. Note: You can link libstdc++ static, leaving others of your choice dynamic. There is a gcc link option for doing just exactly that. http://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 > may recommend that we use the "configure->make->make install" or "rpm/deb" > technique 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 > future 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 -> > libsasl2.so.2.0.22 > lrwxrwxrwx. 1 root root 18 2011-07-08 13:35 /usr/lib/libsasl2.so.2 -> > libsasl2.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 > requires 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 > see 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 > requires 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 > understandable. I wish I had a better mental model of what the principles > here are. People seem to have told me that any library listed must be > followed by every library it calls. I suppose with tools like ldd or nm, I > could work this out, but it doesn't seem very simple. I wish that there were > some kind or multi-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. > > > > > > > > > > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
