Yeah the command line example was working. The example that I sent you the ldd info for. Here's my run for example06 which has been recompiled with some of the seemingly offending code from the program that's dying.
./example06 google.com Content-type: text/plain * About to connect() to google.com port 80 * Trying 74.125.127.100... * connected * Connected to google.com (74.125.127.100) port 80 > GET / HTTP/1.1 Host: google.com Pragma: no-cache Accept: */* < HTTP/1.1 301 Moved Permanently < Location: http://www.google.com/ < Content-Type: text/html; charset=UTF-8 < Date: Mon, 17 Aug 2009 16:55:49 GMT < Expires: Wed, 16 Sep 2009 16:55:49 GMT < Cache-Control: public, max-age=2592000 < Server: gws < Content-Length: 219 <HTML><HEAD><meta http-equiv="content-type" content="text/ html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="http://www.google.com/";>here</A>. </BODY></HTML> * Connection #0 to host google.com left intact * Closing connection #0 And here's the ldd for that same executable. ldd example06 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) So I'm thinking if I recompile libcurlpp to use the same libraries it's using in here, namely libcurl.so.3 instead of libcurl.so.4, libssl.so.0.9.7 instead of libssl.so.4 and libcrypto.so.0.9.7 instead of libcrypto.so.4, the linking errors should resolve themselves. At least that's the theory I've come up with given my limited knowledge of these things. On Aug 17, 12:53 pm, Jean-Philippe Barette-LaPierre <[email protected]> wrote: > On Mon, Aug 17, 2009 at 12:53 PM, Jean-Philippe Barette-LaPierre < > > > > [email protected]> wrote: > > > On Mon, Aug 17, 2009 at 12:41 PM, tatebn <[email protected]> wrote: > > >> Have to figure out which of the many libcurl libs that one refers > >> too. But out of curiosity, since the only discrepancy between the > >> testing.cgi and the example, as far as ldd output goes, is those 3 lib > >> versions, and the 3 seemingly offending libs are brought in by curlpp, > >> if libcurlpp were recompiled to link to the same libs as the example > >> executable, the duplicate libs should not matter because nothing will > >> be linking to them. Is that correct? > > > Probably. The other solution to try would be to link statically the > > libraries > > for your cgi... You wouldn't have that problem.... > > So, you're sure the command line was working? > > > > >> On Aug 17, 12:35 pm, Jean-Philippe Barette-LaPierre > >> <[email protected]> wrote: > >> > remove the lib too (back up them), restart the webserver, so it will try > >> to > >> > reload the libraries. > >> > My suspicion is that the webserver won't restart. > > >> > On Mon, Aug 17, 2009 at 12:30 PM, tatebn <[email protected]> > >> wrote: > > >> > > Nevermind. I just noticed the URL option was still commented out. > >> > > Back to square one. Still dying. > > >> > > On Aug 17, 12:25 pm, tatebn <[email protected]> wrote: > >> > > > I deleted the /usr/local/include/curl folder, after making a tar of > >> it > >> > > > of course, and now the application runs without dying. Test credit > >> > > > card runs gets declined, but that's supposed to happen. Thanks for > >> > > > all your help. Don't forget about me, I might not be out of the > >> woods > >> > > > yet. > > >> > > > On Aug 17, 12:13 pm, tatebn <[email protected]> wrote: > > >> > > > > I understand that I need to get rid of the different libraries, > >> but I > >> > > > > don't know how. I don't want to just rm them because God knows > >> what > >> > > > > kind of hell that will unleash. So I guess I could rename them > >> with a > >> > > > > different extension, perhaps that would be the solution for now. > >> Keep > >> > > > > the .so.4 versions of everything? > > >> > > > > On Aug 17, 12:01 pm, Jean-Philippe Barette-LaPierre > > >> > > > > <[email protected]> wrote: > >> > > > > > On Mon, Aug 17, 2009 at 11:56 AM, tatebn < > >> [email protected]> > >> > > wrote: > > >> > > > > > > I was able to run from the command line, but the executable I > >> ran > >> > > from > >> > > > > > > the command line had those different versions. The older > >> versions. > > >> > > > > > > How do I check the webserver environment libraries? > >> Testing.cgi, > >> > > > > > > which is what gets run from the browser, had different > >> libraries > >> > > from > >> > > > > > > the working example executable as well as duplicates. > > >> > > > > > You need to solve this first. I can't emphasize enough on this > >> point: > >> > > Get > >> > > > > > rid of > >> > > > > > the different libraries. You won't go any further before doing > >> so. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
