I want to say that we recompiled curlpp to use libssl.so.4 and libcurl.so.4 to get rid of those warnings from before. Would recompiling libcurlpp to use libcurl.so.3 and libssl.so.0.9.7 do some good. Also, the guy who was handling those things quit on me... so how would I go about recompiling libcurlpp to use those libraries?
On Aug 17, 11:00 am, tatebn <[email protected]> wrote: > How would I go about doing that? > > On Aug 17, 10:57 am, Jean-Philippe Barette-LaPierre > > <[email protected]> wrote: > > On Mon, Aug 17, 2009 at 10:51 AM, tatebn <[email protected]> wrote: > > > > I replied to the email you sent earlier, but I thought it might be > > > best to post here so everything is in one place. I noticed that the > > > ldd info for example06 earlier didn't have libcurlpp in it. Why would > > > that be? > > > Because it's statically linked. Ok... the only solution is to strace the cgi > > when it > > runs by stracing the webserver. My guess is that the webserver is already > > linked > > to the older version of libcurl, or that it loads the older version of > > libcurl. > > > > ldd libssl.so.0.9.7 > > > libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x4003b000) > > > libdl.so.2 => /lib/libdl.so.2 (0x40140000) > > > libc.so.6 => /lib/tls/libc.so.6 (0x42000000) > > > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) > > > > ldd libssl.so.4 > > > libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x4003b000) > > > libdl.so.2 => /lib/libdl.so.2 (0x40140000) > > > libc.so.6 => /lib/tls/libc.so.6 (0x42000000) > > > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) > > > > ldd libcurlpp.so.0 > > > libcurl.so.4 => /usr/lib/libcurl.so.4 (0x40032000) > > > libidn.so.11 => /usr/lib/libidn.so.11 (0x400c4000) > > > libssh2.so.1 => /usr/lib/libssh2.so.1 (0x400f4000) > > > libssl.so.4 => /lib/libssl.so.4 (0x40115000) > > > libcrypto.so.4 => /usr/lib/libcrypto.so.4 (0x4014a000) > > > libldap.so.2 => /usr/lib/libldap.so.2 (0x4024f000) > > > libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2 > > > (0x40282000) > > > libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x40295000) > > > libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 > > > (0x402f3000) > > > libz.so.1 => /usr/lib/libz.so.1 (0x40303000) > > > libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40311000) > > > libm.so.6 => /lib/tls/libm.so.6 (0x403c4000) > > > libc.so.6 => /lib/tls/libc.so.6 (0x42000000) > > > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x403e7000) > > > libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 > > > (0x403ef000) > > > libresolv.so.2 => /lib/libresolv.so.2 (0x403f1000) > > > libdl.so.2 => /lib/libdl.so.2 (0x40403000) > > > liblber.so.2 => /usr/lib/liblber.so.2 (0x40408000) > > > libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x40414000) > > > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) > > > libcrypt.so.1 => /lib/libcrypt.so.1 (0x40427000) > > > > ldd libcurl.so.3 > > > libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0x40035000) > > > libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x40068000) > > > libdl.so.2 => /lib/libdl.so.2 (0x4016d000) > > > libz.so.1 => /usr/lib/libz.so.1 (0x40171000) > > > libc.so.6 => /lib/tls/libc.so.6 (0x42000000) > > > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) > > > > ldd libcurl.so.4 > > > libssl.so.2 => /lib/libssl.so.2 (0x4009a000) > > > libcrypto.so.2 => /usr/lib/libcrypto.so.2 (0x400cf000) > > > libldap.so.2 => /usr/lib/libldap.so.2 (0x401d4000) > > > libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2 > > > (0x40206000) > > > libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x40219000) > > > libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 > > > (0x40277000) > > > libz.so.1 => /usr/lib/libz.so.1 (0x40288000) > > > libc.so.6 => /lib/tls/libc.so.6 (0x42000000) > > > libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 > > > (0x40296000) > > > libresolv.so.2 => /lib/libresolv.so.2 (0x40298000) > > > libdl.so.2 => /lib/libdl.so.2 (0x402aa000) > > > liblber.so.2 => /usr/lib/liblber.so.2 (0x402ae000) > > > libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x402bb000) > > > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) > > > libcrypt.so.1 => /lib/libcrypt.so.1 (0x402ce000) > > > > /usr/include/curl/curlver.h > > > #define LIBCURL_VERSION "7.19.5" > > > > /usr/local/include/curl/curlver.h > > > #define LIBCURL_VERSION "7.12.2" > > > > On Aug 17, 10:27 am, Jean-Philippe Barette-LaPierre > > > <[email protected]> wrote: > > > > testing.cgi: > > > > libcurl.so.4 => /usr/lib/libcurl.so.4 (0x4048a000) > > > > example06: > > > > libcurl.so.3 => /usr/local/lib/libcurl.so.3 (0x400d1000) > > > > > You need to link with the same library. So, when you compile curlpp AND > > > your > > > > problem, ensure you link > > > > to the same libraries. The different libssl libraries might be from > > > > different packages, meaning from different > > > > distributions. Honestly it seems to be a mess. Can you send a ldd output > > > of: > > > > > libssl.so.0.9.7 > > > > libssl.so.4 > > > > libcurlpp.so.0 > > > > libcurl.so.3 > > > > libcurl.so.4 > > > > > And please send both installed curl version. You seems to have one > > > > in /usr/ and one in /usr/local. So, the version can be retreived by > > > looking > > > > at: > > > > > /usr/include/curl/curlver.h > > > > /usr/local/include/curl/curlver.h > > > > > So, curlpp is linked to libcurl.so.3. I don't know why you got two > > > different > > > > version > > > > > On Mon, Aug 17, 2009 at 10:01 AM, tatebn <[email protected]> wrote: > > > > > > This is the "ldd" output for testing.cgi. > > > > > > libmysqlclient.so.10 => /usr/lib/mysql/libmysqlclient.so.10 > > > > > (0x4001e000) > > > > > libcrypt.so.1 => /lib/libcrypt.so.1 (0x40055000) > > > > > libpfpro.so => /usr/local/verisign/payflowpro/linux/lib/ > > > > > libpfpro.so (0x40082000) > > > > > libcurlpp.so.0 => /usr/lib/libcurlpp.so.0 (0x40128000) > > > > > libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40152000) > > > > > libidn.so.11 => /usr/lib/libidn.so.11 (0x40205000) > > > > > libssh2.so.1 => /usr/lib/libssh2.so.1 (0x40236000) > > > > > libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0x40257000) > > > > > libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x4028a000) > > > > > libldap.so.2 => /usr/lib/libldap.so.2 (0x4038f000) > > > > > libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2 > > > > > (0x403c1000) > > > > > libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x403d4000) > > > > > libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 > > > > > (0x40433000) > > > > > libz.so.1 => /usr/lib/libz.so.1 (0x40443000) > > > > > libm.so.6 => /lib/tls/libm.so.6 (0x40451000) > > > > > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40473000) > > > > > libc.so.6 => /lib/tls/libc.so.6 (0x42000000) > > > > > libpthread.so.0 => /lib/tls/libpthread.so.0 (0x4047b000) > > > > > libcurl.so.4 => /usr/lib/libcurl.so.4 (0x4048a000) > > > > > libnsl.so.1 => /lib/libnsl.so.1 (0x4051c000) > > > > > libssl.so.4 => /lib/libssl.so.4 (0x40531000) > > > > > libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 > > > > > (0x40566000) > > > > > libresolv.so.2 => /lib/libresolv.so.2 (0x40568000) > > > > > libdl.so.2 => /lib/libdl.so.2 (0x4057b000) > > > > > liblber.so.2 => /usr/lib/liblber.so.2 (0x4057f000) > > > > > libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x4058b000) > > > > > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > > > > > > But the odd thing is, it's all good from the command line. I switched > > > > > the owner and group for example06 to match that of testing.cgi and it > > > > > still ran just fine. Looks like test.cgi is loading two versions of > > > > > libssl.so. > > > > > > here's ldd for example06. There are some significant differences. > > > > > example06 is apparently not even loading curlpp. And there are > > > > > version diffs that could be significant. Let me know what you think. > > > > > > libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4001e000) > > > > > libcurl.so.3 => /usr/local/lib/libcurl.so.3 (0x400d1000) > > > > > libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0x400fe000) > > > > > libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x40131000) > > > > > libdl.so.2 => /lib/libdl.so.2 (0x40236000) > > > > > libz.so.1 => /usr/lib/libz.so.1 (0x4023a000) > > > > > libm.so.6 => /lib/tls/libm.so.6 (0x40249000) > > > > > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4026b000) > > > > > libc.so.6 => /lib/tls/libc.so.6 (0x42000000) > > > > > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > > > > > > On Aug 17, 9:10 am, Jean-Philippe Barette-LaPierre > > > > > <[email protected]> wrote: > > > > > > On Sun, Aug 16, 2009 at 6:55 PM, tatebn <[email protected]> > > > wrote: > > > > > > > > It looks at this point like everything is find if the URL option > > > isn't > > > > > > > set. Any idea why that would be? I don't know enough about > > > incoming/ > > > > > > > outgoing connection setttings to know how to check whether or not > > > the > > > > > > > cgi is allowed to connect to anything. My current guess is that > > > it's > > > > > > > not, and that's why it dies with an outgoing connection. Any > > > insight > > > > > > > or helpful advice? > > > > > > > can you send the "ldd" output for your cgi, curlpp and libcurl? > > > > > > if you don't know what is ldd, type this on the command line: > > > > > > > man ldd > > > > > > > > Thanks, > > > > > > > Brandon > > > > > > > > On Aug 16, 12:17 am, tatebn <[email protected]> wrote: > > > > > > > > So it looks like > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "curlpp" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/curlpp?hl=en -~----------~----~----~----~------~----~------~--~---
