tatebn
Mon, 17 Aug 2009 08:01:04 -0700
How would I go about doing that? On Aug 17, 10:57 am, Jean-Philippe Barette-LaPierre <jpbarre...@gmail.com> wrote: > On Mon, Aug 17, 2009 at 10:51 AM, tatebn <brandonnt...@gmail.com> 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 > > <jpbarre...@gmail.com> 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 <brandonnt...@gmail.com> 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 > > > > <jpbarre...@gmail.com> wrote: > > > > > On Sun, Aug 16, 2009 at 6:55 PM, tatebn <brandonnt...@gmail.com> > > 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 <brandonnt...@gmail.com> wrote: > > > > > > > So it looks like the curlpp examples are working, but the program > > I > > > > > > > need to work still isn't. Here's the code, what in here would > > make > > > > > > > perform() die? > > > > > > > > Note: perform() also dies if I comment out all the options except > > > > > > > host. > > > > > //-------------------------------------------------------------------- > > > > > > > // Includes > > > > > //-------------------------------------------------------------------- > > > > > > > #include "verisign_io.h" > > > > > > > #include "file_io.h" > > > > > > > #include "error_lib.h" > > > > > > > #include "logging.h" > > > > > > > #include "toolkit.h" > > > > > > > #include "parm.h" > > > > > > > > //using current time in seconds and credit card number for unique > > > > > > > transaction id > > > > > > > #include > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "curlpp" group. To post to this group, send email to curlpp@googlegroups.com To unsubscribe from this group, send email to curlpp+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/curlpp?hl=en -~----------~----~----~----~------~----~------~--~---