On Wed, Jul 20, 2011 at 8:48 AM, <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. http://asg.web.cmu.edu/sasl/sasl-library.html
> 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. The compiler only needs to produce relocatable code/non-relocatable code. Its up to the linker to glue it together. To pass linker flags, one usually uses -Wl from the front end. If you not using GCC to pass linker flags, one usually uses '-c' to compile, and then calls `ld` directly with tflags such as -Bstatic. Have you been doing one or the other? Or are you mixing them? > 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. Welcome to the world of Linux! Wait until you try an build something that needs fetch six or eight bleeding edge/unstable packages due to dependencies. GLIBC uses the proverbial 'call gate' to interact with the operating system. On Linux, its a syscall and and the defined calls (such as printf -> write) are defined in .../kernel/syscall.c. For example, see arch/x86/kernel/syscall_64.c. Robert Love gives a very good description of the process in Linux Kernel Development. Also see syscall(2) at http://linux.die.net/man/2/syscalls. > 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. DLL hell is alive and well, even on Linux! > That leaves me with telling users that they must update gcc > and gcc-c++, not completely unreasonable, > perhaps. I see you've never tried to build binutils and gcc ;) Make sure you join the GCC-Help Mailing List at http://gcc.gnu.org/lists.html. Jonathan Wakely and Ian Lance Taylor do a great job (I hope they publish an up to date book on GCC one day). > 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. In the end, I think you're fighting something that is fundamental to Linux. You might consider familiarizing yourself with a Linux Shared Library HowTo: Drepper's www.akkadia.org/drepper/dsohowto.pdf, http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html or http://tldp.org/HOWTO/Program-Library-HOWTO/. Finally, you might find one of the comp.os.linux groups to be a better resource. For example, comp.os.linux.development (see http://groups.google.com/groups/dir?sel=usenet%3Dcomp.os.linux%2C). Jeff > -----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. >> >> [SNIP] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
