curlpp - cURLpp is a C++ wrapper for libcURL

Last 30 days Jan 27, 2012 Compilers Wiki page commented on by mjmen...@gmail.com - how to use with dev c++. I am new to curlpp as well as dev c++. Please instruct me. Thank you... how to use with dev c++. I am new to curlpp as well as dev c++. Please instruct me. Thank you... Jan 27, 2012 Compilers Wiki page commented on by mjmen...@gmail.com - juuu juuu Jan 27, 2012 issue 1 (move internals to separate namespace and folders) commented on by sanjay.a...@gmail.com - Hello, The internal headers should not be referenced by the public headers. It make using the library kinda difficult. Here's one bug https://bugzilla.redhat.com/show_bug.cgi?id=784614 Can this one please be fixed? :) Thanks! Hello, The internal headers should not be referenced by the public headers. It make using the library kinda difficult. Here's one bug https://bugzilla.redhat.com/show_bug.cgi?id=784614 Can this one please be fixed? :) Thanks! Older Aug 28, 2011 issue 22 (Defect) reported by squarew...@yahoo.de - What steps will reproduce the problem? 1. 2. 3. What is the expected output? What do you see instead? What version of the product are you using? On what operating system? Please provide any additional information below. What steps will reproduce the problem? 1. 2. 3. What is the expected output? What do you see instead? What version of the product are you using? On what operating system? Please provide any additional information below. Jun 09, 2011 Compilers Wiki page commented on by dumbdumb...@gmail.com - Hi, I compiled libcurl with mingw nicely, and I put the libcurldll.a in my lib directory and the "curl" include directory in my include directory. How to compile the curlpp with mingw, in such a way to get some kind of single curlpp.a library file? Meaning, in my project I would only need to link a curlpp.a (and reference the curlpp header files). It's not clear how would I do that? Thanks. Hi, I compiled libcurl with mingw nicely, and I put the libcurldll.a in my lib directory and the "curl" include directory in my include directory. How to compile the curlpp with mingw, in such a way to get some kind of single curlpp.a library file? Meaning, in my project I would only need to link a curlpp.a (and reference the curlpp header files). It's not clear how would I do that? Thanks. Jun 09, 2011 Compilers Wiki page commented on by mathieu....@gmail.com - Hi, I compiled libcurl with mingw nicely, and I put the libcurldll.a in my lib directory and the "curl" include directory in my include directory. How to compile the curlpp with mingw, in such a way to get some kind of single curlpp.a library file? Meaning, in my project I would only need to link a curlpp.a (and reference the curlpp header files). It's not clear how would I do that? Thanks. Hi, I compiled libcurl with mingw nicely, and I put the libcurldll.a in my lib directory and the "curl" include directory in my include directory. How to compile the curlpp with mingw, in such a way to get some kind of single curlpp.a library file? Meaning, in my project I would only need to link a curlpp.a (and reference the curlpp header files). It's not clear how would I do that? Thanks. Feb 02, 2011 issue 21 (Callbacks created on stack should be disabled when leaving t...) reported by terrade...@gmail.com - Using latest curlpp with latest libcurl, on debian lenny. I am using curlpp Write and WriteHeader callbacks by creating their objects on the stack and then setting the options in the Easy curlpp object. However the Easy object itself is created somewhere outside the function when callbacks are set, it is used for persistent connections. All the request options are reset for each request for the same Easy object. Usually I have http requests and the design works without any problem. But then I had some ftp request coming through my application. At some point the connection was about to be closed, and it resulted in some "Good bye" ftp header received, and a crash with the following stack: 0x00000005 in ?? () #1 0xa50905cb in myapp::WriteHeaderCallback::WriteHeaderCallbackFunction (this=0xef1d6980, ptr=0x64bed5dc "221 Goodbye.\r\nompleted.\r", size=1, nmemb=14) at myapp/myapp.cpp:312 #2 0xa506e5f1 in utilspp::MemFunHandler<utilspp::Functor<unsigned int, utilspp::tl::TypeList<char, utilspp::tl::TypeList<unsigned int, utilspp::tl::TypeList<unsigned int, utilspp::NullType> > > >, myapp::WriteHeaderCallback, unsigned int (myapp::WriteHeaderCallback::)(char, unsigned int, unsigned int)>::operator() (this=0xb285abb8, p1=0x64bed5dc "221 Goodbye.\r\nompleted.\r", p2=1, p3=14) at /usr/include/utilspp/functor/MemFunHandler.hpp:55 #3 0xe412f86d in utilspp::Functor<unsigned int, utilspp::tl::TypeList<char, utilspp::tl::TypeList<unsigned int, utilspp::tl::TypeList<unsigned int, utilspp::NullType> > > >::operator() (this=0x64bf5920, p1=0x64bed5dc "221 Goodbye.\r\nompleted.\r", p2=1, p3=14) at ../../../include/utilspp/functor/Functor.hpp:106 #4 0xe412e370 in curlpp::internal::CurlHandle::executeHeaderFunctor (this=0x64bf5810, buffer=0x64bed5dc "221 Goodbye.\r\nompleted.\r", size=1, nitems=14) at CurlHandle.cpp:199 #5 0xe4135673 in curlpp::internal::Callbacks::HeaderCallback (buffer=0x64bed5dc "221 Goodbye.\r\nompleted.\r", size=1, nitems=14, handle=0x64bf5810) at OptionSetter.cpp:66 #6 0xf711c398 in Curl_client_write (conn=0xbae6a094, type=<value optimized out>, ptr=0x64bed5dc "221 Goodbye.\r\nompleted.\r", len=14) at sendf.c:489 #7 0xf7150882 in Curl_pp_readresp (sockfd=87, pp=0xbae6a444, code=0xef1d7648, size=0xef1d7740) at pingpong.c:398 #8 0xf711d1af in ftp_readresp (sockfd=-1525497406, pp=0xef1d6984, ftpcode=0xef1d7744, size=0xef1d7740) at ftp.c:401 #9 0xf711f94b in ftp_statemach_act (conn=0xbae6a094) at ftp.c:2406 #10 0xf7150feb in Curl_pp_easy_statemach (pp=0xbae6a444) at pingpong.c:154 #11 0xf711ca6e in ftp_disconnect (conn=0xbae6a094, dead_connection=false) at ftp.c:2831 #12 0xf71241d9 in Curl_disconnect (conn=0xbae6a094, dead_connection=194) at url.c:2650 #13 0xf7124c57 in ConnectionKillOne (data=0x64bed11c) at url.c:3101 #14 0xf71290ef in Curl_close (data=0x64bed11c) at url.c:279 #15 0xf7136e41 in curl_easy_cleanup (curl=0xa512c1c2) at easy.c:582 #16 0xe412e783 in ~CurlHandle (this=0x64bf5810) at CurlHandle.cpp:110 #17 0xa506d6d7 in ~auto_ptr (this=0xb773476c) at /usr/include/c++/4.3/backward/auto_ptr.h:173 #18 0xe4126998 in ~Easy (this=0xb7734768) at Easy.cpp:42 The thing is that this was called outside the function that instantiates my WriteHeaderCallback, so there is nothing surprising that everything ended up with a crash. I don't think that this is an extraordinary situation, when the Easy object is reused for multiple requests. But now I realize, that some options should be reset if they are created using the stack objects and they are leaving the stack. Some options are probably harmless, they simply set some libcurl flags, however callbacks are dangerous to leave and they should be reset explicitly. The alternative might be to use static callbacks object, or allocate them dynamically, however they both would result in even more difficult problems (synchronization, or questions when to deallocate dynamic object). The current idea of allocating callbacks and functors on the stack is good enough most of the time. I think the solution is to reset libcurl callback options in the destructor of curlpp callback objects. For now I will try to reset the curl options using the libcurl C API in that specific function of mine, however I am looking forward to a proper solution in curlpp. Using latest curlpp with latest libcurl, on debian lenny. I am using curlpp Write and WriteHeader callbacks by creating their objects on the stack and then setting the options in the Easy curlpp object. However the Easy object itself is created somewhere outside the function when callbacks are set, it is used for persistent connections. All the request options are reset for each request for the same Easy object. Usually I have http requests and the design works without any problem. But then I had some ftp request coming through my application. At some point the connection was about to be closed, and it resulted in some "Good bye" ftp header received, and a crash with the following stack: 0x00000005 in ?? () #1 0xa50905cb in myapp::WriteHeaderCallback::WriteHeaderCallbackFunction (this=0xef1d6980, ptr=0x64bed5dc "221 Goodbye.\r\nompleted.\r", size=1, nmemb=14) at myapp/myapp.cpp:312 #2 0xa506e5f1 in utilspp::MemFunHandler<utilspp::Functor<unsigned int, utilspp::tl::TypeList<char, utilspp::tl::TypeList<unsigned int, utilspp::tl::TypeList<unsigned int, utilspp::NullType> > > >, myapp::WriteHeaderCallback, unsigned int (myapp::WriteHeaderCallback::)(char, unsigned int, unsigned int)>::operator() (this=0xb285abb8, p1=0x64bed5dc "221 Goodbye.\r\nompleted.\r", p2=1, p3=14) at /usr/include/utilspp/functor/MemFunHandler.hpp:55 #3 0xe412f86d in utilspp::Functor<unsigned int, utilspp::tl::TypeList<char, utilspp::tl::TypeList<unsigned int, utilspp::tl::TypeList<unsigned int, utilspp::NullType> > > >::operator() (this=0x64bf5920, p1=0x64bed5dc "221 Goodbye.\r\nompleted.\r", p2=1, p3=14) at ../../../include/utilspp/functor/Functor.hpp:106 #4 0xe412e370 in curlpp::internal::CurlHandle::executeHeaderFunctor (this=0x64bf5810, buffer=0x64bed5dc "221 Goodbye.\r\nompleted.\r", size=1, nitems=14) at CurlHandle.cpp:199 #5 0xe4135673 in curlpp::internal::Callbacks::HeaderCallback (buffer=0x64bed5dc "221 Goodbye.\r\nompleted.\r", size=1, nitems=14, handle=0x64bf5810) at OptionSetter.cpp:66 #6 0xf711c398 in Curl_client_write (conn=0xbae6a094, type=<value optimized out>, ptr=0x64bed5dc "221 Goodbye.\r\nompleted.\r", len=14) at sendf.c:489 #7 0xf7150882 in Curl_pp_readresp (sockfd=87, pp=0xbae6a444, code=0xef1d7648, size=0xef1d7740) at pingpong.c:398 #8 0xf711d1af in ftp_readresp (sockfd=-1525497406, pp=0xef1d6984, ftpcode=0xef1d7744, size=0xef1d7740) at ftp.c:401 #9 0xf711f94b in ftp_statemach_act (conn=0xbae6a094) at ftp.c:2406 #10 0xf7150feb in Curl_pp_easy_statemach (pp=0xbae6a444) at pingpong.c:154 #11 0xf711ca6e in ftp_disconnect (conn=0xbae6a094, dead_connection=false) at ftp.c:2831 #12 0xf71241d9 in Curl_disconnect (conn=0xbae6a094, dead_connection=194) at url.c:2650 #13 0xf7124c57 in ConnectionKillOne (data=0x64bed11c) at url.c:3101 #14 0xf71290ef in Curl_close (data=0x64bed11c) at url.c:279 #15 0xf7136e41 in curl_easy_cleanup (curl=0xa512c1c2) at easy.c:582 #16 0xe412e783 in ~CurlHandle (this=0x64bf5810) at CurlHandle.cpp:110 #17 0xa506d6d7 in ~auto_ptr (this=0xb773476c) at /usr/include/c++/4.3/backward/auto_ptr.h:173 #18 0xe4126998 in ~Easy (this=0xb7734768) at Easy.cpp:42 The thing is that this was called outside the function that instantiates my WriteHeaderCallback, so there is nothing surprising that everything ended up with a crash. I don't think that this is an extraordinary situation, when the Easy object is reused for multiple requests. But now I realize, that some options should be reset if they are created using the stack objects and they are leaving the stack. Some options are probably harmless, they simply set some libcurl flags, however callbacks are dangerous to leave and they should be reset explicitly. The alternative might be to use static callbacks object, or allocate them dynamically, however they both would result in even more difficult problems (synchronization, or questions when to deallocate dynamic object). The current idea of allocating callbacks and functors on the stack is good enough most of the time. I think the solution is to reset libcurl callback options in the destructor of curlpp callback objects. For now I will try to reset the curl options using the libcurl C API in that specific function of mine, however I am looking forward to a proper solution in curlpp. Feb 02, 2011 issue 21 (Callbacks created on stack should be disabled when leaving t...) reported by terrade...@gmail.com - Using latest curlpp with latest libcurl, on debian lenny. I am using curlpp Write and WriteHeader callbacks by creating their objects on the stack and then setting the options in the Easy curlpp object. However the Easy object itself is created somewhere outside the function when callbacks are set, it is used for persistent connections. All the request options are reset for each request for the same Easy object. Usually I have http requests and the design works without any problem. But then I had some ftp request coming through my application. At some point the connection was about to be closed, and it resulted in some "Good bye" ftp header received, and a crash with the following stack: 0x00000005 in ?? () #1 0xa50905cb in myapp::WriteHeaderCallback::WriteHeaderCallbackFunction (this=0xef1d6980, ptr=0x64bed5dc "221 Goodbye.\r\nompleted.\r", size=1, nmemb=14) at myapp/myapp.cpp:312 #2 0xa506e5f1 in utilspp::MemFunHandler<utilspp::Functor<unsigned int, utilspp::tl::TypeList<char, utilspp::tl::TypeList<unsigned int, utilspp::tl::TypeList<unsigned int, utilspp::NullType> > > >, myapp::WriteHeaderCallback, unsigned int (myapp::WriteHeaderCallback::)(char, unsigned int, unsigned int)>::operator() (this=0xb285abb8, p1=0x64bed5dc "221 Goodbye.\r\nompleted.\r", p2=1, p3=14) at /usr/include/utilspp/functor/MemFunHandler.hpp:55 #3 0xe412f86d in utilspp::Functor<unsigned int, utilspp::tl::TypeList<char, utilspp::tl::TypeList<unsigned int, utilspp::tl::TypeList<unsigned int, utilspp::NullType> > > >::operator() (this=0x64bf5920, p1=0x64bed5dc "221 Goodbye.\r\nompleted.\r", p2=1, p3=14) at ../../../include/utilspp/functor/Functor.hpp:106 #4 0xe412e370 in curlpp::internal::CurlHandle::executeHeaderFunctor (this=0x64bf5810, buffer=0x64bed5dc "221 Goodbye.\r\nompleted.\r", size=1, nitems=14) at CurlHandle.cpp:199 #5 0xe4135673 in curlpp::internal::Callbacks::HeaderCallback (buffer=0x64bed5dc "221 Goodbye.\r\nompleted.\r", size=1, nitems=14, handle=0x64bf5810) at OptionSetter.cpp:66 #6 0xf711c398 in Curl_client_write (conn=0xbae6a094, type=<value optimized out>, ptr=0x64bed5dc "221 Goodbye.\r\nompleted.\r", len=14) at sendf.c:489 #7 0xf7150882 in Curl_pp_readresp (sockfd=87, pp=0xbae6a444, code=0xef1d7648, size=0xef1d7740) at pingpong.c:398 #8 0xf711d1af in ftp_readresp (sockfd=-1525497406, pp=0xef1d6984, ftpcode=0xef1d7744, size=0xef1d7740) at ftp.c:401 #9 0xf711f94b in ftp_statemach_act (conn=0xbae6a094) at ftp.c:2406 #10 0xf7150feb in Curl_pp_easy_statemach (pp=0xbae6a444) at pingpong.c:154 #11 0xf711ca6e in ftp_disconnect (conn=0xbae6a094, dead_connection=false) at ftp.c:2831 #12 0xf71241d9 in Curl_disconnect (conn=0xbae6a094, dead_connection=194) at url.c:2650 #13 0xf7124c57 in ConnectionKillOne (data=0x64bed11c) at url.c:3101 #14 0xf71290ef in Curl_close (data=0x64bed11c) at url.c:279 #15 0xf7136e41 in curl_easy_cleanup (curl=0xa512c1c2) at easy.c:582 #16 0xe412e783 in ~CurlHandle (this=0x64bf5810) at CurlHandle.cpp:110 #17 0xa506d6d7 in ~auto_ptr (this=0xb773476c) at /usr/include/c++/4.3/backward/auto_ptr.h:173 #18 0xe4126998 in ~Easy (this=0xb7734768) at Easy.cpp:42 The thing is that this was called outside the function that instantiates my WriteHeaderCallback, so there is nothing surprising that everything ended up with a crash. I don't think that this is an extraordinary situation, when the Easy object is reused for multiple requests. But now I realize, that some options should be reset if they are created using the stack objects and they are leaving the stack. Some options are probably harmless, they simply set some libcurl flags, however callbacks are dangerous to leave and they should be reset explicitly. The alternative might be to use static callbacks object, or allocate them dynamically, however they both would result in even more difficult problems (synchronization, or questions when to deallocate dynamic object). The current idea of allocating callbacks and functors on the stack is good enough most of the time. I think the solution is to reset libcurl callback options in the destructor of curlpp callback objects. For now I will try to reset the curl options using the libcurl C API in that specific function of mine, however I am looking forward to a proper solution in curlpp. Using latest curlpp with latest libcurl, on debian lenny. I am using curlpp Write and WriteHeader callbacks by creating their objects on the stack and then setting the options in the Easy curlpp object. However the Easy object itself is created somewhere outside the function when callbacks are set, it is used for persistent connections. All the request options are reset for each request for the same Easy object. Usually I have http requests and the design works without any problem. But then I had some ftp request coming through my application. At some point the connection was about to be closed, and it resulted in some "Good bye" ftp header received, and a crash with the following stack: 0x00000005 in ?? () #1 0xa50905cb in myapp::WriteHeaderCallback::WriteHeaderCallbackFunction (this=0xef1d6980, ptr=0x64bed5dc "221 Goodbye.\r\nompleted.\r", size=1, nmemb=14) at myapp/myapp.cpp:312 #2 0xa506e5f1 in utilspp::MemFunHandler<utilspp::Functor<unsigned int, utilspp::tl::TypeList<char, utilspp::tl::TypeList<unsigned int, utilspp::tl::TypeList<unsigned int, utilspp::NullType> > > >, myapp::WriteHeaderCallback, unsigned int (myapp::WriteHeaderCallback::)(char, unsigned int, unsigned int)>::operator() (this=0xb285abb8, p1=0x64bed5dc "221 Goodbye.\r\nompleted.\r", p2=1, p3=14) at /usr/include/utilspp/functor/MemFunHandler.hpp:55 #3 0xe412f86d in utilspp::Functor<unsigned int, utilspp::tl::TypeList<char, utilspp::tl::TypeList<unsigned int, utilspp::tl::TypeList<unsigned int, utilspp::NullType> > > >::operator() (this=0x64bf5920, p1=0x64bed5dc "221 Goodbye.\r\nompleted.\r", p2=1, p3=14) at ../../../include/utilspp/functor/Functor.hpp:106 #4 0xe412e370 in curlpp::internal::CurlHandle::executeHeaderFunctor (this=0x64bf5810, buffer=0x64bed5dc "221 Goodbye.\r\nompleted.\r", size=1, nitems=14) at CurlHandle.cpp:199 #5 0xe4135673 in curlpp::internal::Callbacks::HeaderCallback (buffer=0x64bed5dc "221 Goodbye.\r\nompleted.\r", size=1, nitems=14, handle=0x64bf5810) at OptionSetter.cpp:66 #6 0xf711c398 in Curl_client_write (conn=0xbae6a094, type=<value optimized out>, ptr=0x64bed5dc "221 Goodbye.\r\nompleted.\r", len=14) at sendf.c:489 #7 0xf7150882 in Curl_pp_readresp (sockfd=87, pp=0xbae6a444, code=0xef1d7648, size=0xef1d7740) at pingpong.c:398 #8 0xf711d1af in ftp_readresp (sockfd=-1525497406, pp=0xef1d6984, ftpcode=0xef1d7744, size=0xef1d7740) at ftp.c:401 #9 0xf711f94b in ftp_statemach_act (conn=0xbae6a094) at ftp.c:2406 #10 0xf7150feb in Curl_pp_easy_statemach (pp=0xbae6a444) at pingpong.c:154 #11 0xf711ca6e in ftp_disconnect (conn=0xbae6a094, dead_connection=false) at ftp.c:2831 #12 0xf71241d9 in Curl_disconnect (conn=0xbae6a094, dead_connection=194) at url.c:2650 #13 0xf7124c57 in ConnectionKillOne (data=0x64bed11c) at url.c:3101 #14 0xf71290ef in Curl_close (data=0x64bed11c) at url.c:279 #15 0xf7136e41 in curl_easy_cleanup (curl=0xa512c1c2) at easy.c:582 #16 0xe412e783 in ~CurlHandle (this=0x64bf5810) at CurlHandle.cpp:110 #17 0xa506d6d7 in ~auto_ptr (this=0xb773476c) at /usr/include/c++/4.3/backward/auto_ptr.h:173 #18 0xe4126998 in ~Easy (this=0xb7734768) at Easy.cpp:42 The thing is that this was called outside the function that instantiates my WriteHeaderCallback, so there is nothing surprising that everything ended up with a crash. I don't think that this is an extraordinary situation, when the Easy object is reused for multiple requests. But now I realize, that some options should be reset if they are created using the stack objects and they are leaving the stack. Some options are probably harmless, they simply set some libcurl flags, however callbacks are dangerous to leave and they should be reset explicitly. The alternative might be to use static callbacks object, or allocate them dynamically, however they both would result in even more difficult problems (synchronization, or questions when to deallocate dynamic object). The current idea of allocating callbacks and functors on the stack is good enough most of the time. I think the solution is to reset libcurl callback options in the destructor of curlpp callback objects. For now I will try to reset the curl options using the libcurl C API in that specific function of mine, however I am looking forward to a proper solution in curlpp. Jan 08, 2011 Compilers Wiki page commented on by clm971910 - In file included from Easy.cpp:25: ../../include/curlpp/Options.hpp:281: error: `CURLOPT_FTP_FILEMETHOD' was not declared in this scope ../../include/curlpp/Options.hpp:281: error: template argument 2 is invalid ../../include/curlpp/Options.hpp:281: error: ISO C++ forbids declaration of `FtpFileMethod' with no type ../../include/curlpp/Options.hpp:285: error: `curl_ftpauth' was not declared in this scope ../../include/curlpp/Options.hpp:285: error: `CURLOPT_FTPSSLAUTH' was not declared in this scope ../../include/curlpp/Options.hpp:285: error: template argument 1 is invalid ../../include/curlpp/Options.hpp:285: error: template argument 2 is invalid ../../include/curlpp/Options.hpp:285: error: ISO C++ forbids declaration of `FtpSslAuth' with no type In file included from Easy.cpp:25: ../../include/curlpp/Options.hpp:281: error: `CURLOPT_FTP_FILEMETHOD' was not declared in this scope ../../include/curlpp/Options.hpp:281: error: template argument 2 is invalid ../../include/curlpp/Options.hpp:281: error: ISO C++ forbids declaration of `FtpFileMethod' with no type ../../include/curlpp/Options.hpp:285: error: `curl_ftpauth' was not declared in this scope ../../include/curlpp/Options.hpp:285: error: `CURLOPT_FTPSSLAUTH' was not declared in this scope ../../include/curlpp/Options.hpp:285: error: template argument 1 is invalid ../../include/curlpp/Options.hpp:285: error: template argument 2 is invalid ../../include/curlpp/Options.hpp:285: error: ISO C++ forbids declaration of `FtpSslAuth' with no type Oct 18, 2010 issue 20 (curlpp::infos::ContentLengthDownload::get(request) Core Dump...) reported by codingstandards - What steps will reproduce the problem? 1. in example04.cpp, add the following code at line 80 std::cout << "Content Length Download: " << curlpp::infos::ContentLengthDownload::get(request) << std::endl; 2. make 3. run example04 ./example04 http://www.sunrisecorp.net/ Core dumped What is the expected output? What do you see instead? fill bug What version of the product are you using? On what operating system? 0.7.3 Linux RHEL5.5 Please provide any additional information below. Problem in src/curlpp/Info.cpp template<> void InfoTypeConverter<double>::get(curlpp::Easy & handle, CURLINFO info, double & value) { std::cerr << "KKKKK info=" << info << std::endl; //curl_off_t tmp; double tmp; // for test InfoGetter::get(handle, info, tmp); value = (double)tmp; } What steps will reproduce the problem? 1. in example04.cpp, add the following code at line 80 std::cout << "Content Length Download: " << curlpp::infos::ContentLengthDownload::get(request) << std::endl; 2. make 3. run example04 ./example04 http://www.sunrisecorp.net/ Core dumped What is the expected output? What do you see instead? fill bug What version of the product are you using? On what operating system? 0.7.3 Linux RHEL5.5 Please provide any additional information below. Problem in src/curlpp/Info.cpp template<> void InfoTypeConverter<double>::get(curlpp::Easy & handle, CURLINFO info, double & value) { std::cerr << "KKKKK info=" << info << std::endl; //curl_off_t tmp; double tmp; // for test InfoGetter::get(handle, info, tmp); value = (double)tmp; } Aug 18, 2010 issue 19 (Added a curlpp::FormParts::FileBuf class that upload data in...) reported by yanggehua - Hi, curlpp::FormParts::File class only attaches a file on disk to the POST request. As the situation comes up where I need to send the data in a buffer as the content of upload, I created this curlpp::FormParts::FileBuf class to carry out this job. Please review and comment. Hi, curlpp::FormParts::File class only attaches a file on disk to the POST request. As the situation comes up where I need to send the data in a buffer as the content of upload, I created this curlpp::FormParts::FileBuf class to carry out this job. Please review and comment. Jul 11, 2010 issue 18 (Should check for a zero pointer in InfoTypeConverter<std::st...) commented on by terradepaz - In fact the same check should be applied to the InfoTypeConverter<std::list<std::string> >::get as well - getting a list of cookies may result in a zero pointer. The patch may look as follows: # diff -urN curlpp-0.7.3.orig/src/curlpp/Info.cpp curlpp-0.7.3/src/curlpp/Info.cpp --- curlpp-0.7.3.orig/src/curlpp/Info.cpp 2009-12-05 23:33:38.000000000 +0000 +++ curlpp-0.7.3/src/curlpp/Info.cpp 2010-07-11 20:00:19.000000000 +0000 @@ -19,7 +19,10 @@ { char * tmp; InfoGetter::get(handle, info, tmp); - value = tmp; + if ( tmp != 0 ) + { + value = tmp; + } } @@ -31,8 +34,11 @@ { curl_slist * tmpList = NULL; InfoGetter::get(handle, info, tmpList); + if ( tmpList != 0 ) + { internal::SList slist(tmpList); - value = slist.list(); + value = slist.list(); + } } In fact the same check should be applied to the InfoTypeConverter<std::list<std::string> >::get as well - getting a list of cookies may result in a zero pointer. The patch may look as follows: # diff -urN curlpp-0.7.3.orig/src/curlpp/Info.cpp curlpp-0.7.3/src/curlpp/Info.cpp --- curlpp-0.7.3.orig/src/curlpp/Info.cpp 2009-12-05 23:33:38.000000000 +0000 +++ curlpp-0.7.3/src/curlpp/Info.cpp 2010-07-11 20:00:19.000000000 +0000 @@ -19,7 +19,10 @@ { char * tmp; InfoGetter::get(handle, info, tmp); - value = tmp; + if ( tmp != 0 ) + { + value = tmp; + } } @@ -31,8 +34,11 @@ { curl_slist * tmpList = NULL; InfoGetter::get(handle, info, tmpList); + if ( tmpList != 0 ) + { internal::SList slist(tmpList); - value = slist.list(); + value = slist.list(); + } } Jul 11, 2010 issue 18 (Should check for a zero pointer in InfoTypeConverter<std::st...) reported by terradepaz - What version of the product are you using? On what operating system? curlpp 0.7.3 on debian-lenny. According to the libcurl, the curl_easy_getinfo may return a zero. The InfoTypeConverter<std::string>::get function however doesn't check for this, resulting in a segmentation fault in the string assignment following the call to InfoGetter::get(handle, info, tmp). Solution - should check whether the pointer isn't a zero. What version of the product are you using? On what operating system? curlpp 0.7.3 on debian-lenny. According to the libcurl, the curl_easy_getinfo may return a zero. The InfoTypeConverter<std::string>::get function however doesn't check for this, resulting in a segmentation fault in the string assignment following the call to InfoGetter::get(handle, info, tmp). Solution - should check whether the pointer isn't a zero. Jun 19, 2010 issue 17 (No API) reported by glethro - What steps will reproduce the problem? 1. Go to: http://api.curlpp.org/ 2. Click API 3. About/Home page loads in content area (complete with side bar) 3.1 click API in newly loaded sidebar 3.2 About/home page loads in the content area of the content area... and so on What is the expected output? What do you see instead? I expect to see the content area filled with the api, instead the main page loads there. What browser are you using? On what operating system? Chrome and firefox on Ubuntu Lucid and Karmic Please provide any additional information below. See the screen shots What steps will reproduce the problem? 1. Go to: http://api.curlpp.org/ 2. Click API 3. About/Home page loads in content area (complete with side bar) 3.1 click API in newly loaded sidebar 3.2 About/home page loads in the content area of the content area... and so on What is the expected output? What do you see instead? I expect to see the content area filled with the api, instead the main page loads there. What browser are you using? On what operating system? Chrome and firefox on Ubuntu Lucid and Karmic Please provide any additional information below. See the screen shots Jun 08, 2010 DevelopmentPlans Wiki page commented on by hvjunk - At least can we have some "patches" uploaded etc. for the changes for the latest libcURL before 0.8.0? At least can we have some "patches" uploaded etc. for the changes for the latest libcURL before 0.8.0? Dec 05, 2009 curlpp-0.7.3.tar.gz (latest stable version) file uploaded by jpbarrette - Labels: Featured OpSys-All Type-Source Labels: Featured OpSys-All Type-Source Dec 05, 2009 curlpp-0.7.3.tar.gz (last stable version) file uploaded by jpbarrette Oct 22, 2009 issue 16 (Compile issue on MingW) commented on by dwmcqueen - I think it is a related error - some of the function declarations are being ignored due to the dllimport issue - do you have your CodeBlocks project file? I think it is a related error - some of the function declarations are being ignored due to the dllimport issue - do you have your CodeBlocks project file? Oct 22, 2009 issue 16 (Compile issue on MingW) commented on by dwmcqueen - My compile was using MinGW with GCC 4.4.1 from here - http://www.tdragon.net/recentgcc/ My compile was using MinGW with GCC 4.4.1 from here - http://www.tdragon.net/recentgcc/ Oct 21, 2009 issue 16 (Compile issue on MingW) commented on by cinudata - I am getting linker issue in code::blocks obj\Release\downloads\curlpp\curlpp- 0.7.2\examples\example22.o:example22.cpp:(.text+0x11f)\|\|undefined reference to `__imp___ZN6cURLpp7CleanupC1Ev'\| obj\Release\downloads\curlpp\curlpp- 0.7.2\examples\example22.o:example22.cpp:(.text+0x131)\|\|undefined reference to `__imp___ZN6cURLpp4EasyC1Ev'\| obj\Release\downloads\curlpp\curlpp- 0.7.2\examples\example22.o:example22.cpp:(.text+0x1bd)\|\|undefined reference to `cURLpp::Easy::setOpt(cURLpp::OptionBase)'\| obj\Release\downloads\curlpp\curlpp- 0.7.2\examples\example22.o:example22.cpp:(.text+0x1f3)\|\|undefined reference to `operator<<(std::ostream&, cURLpp::Easy const&)'\| obj\Release\downloads\curlpp\curlpp- 0.7.2\examples\example22.o:example22.cpp:(.text+0x263)\|\|undefined reference to `operator<<(std::ostream&, cURLpp::OptionTrait<std::string, (CURLoption)10002> const&)'\| obj\Release\downloads\curlpp\curlpp- 0.7.2\examples\example22.o:example22.cpp:(.text+0x2bd)\|\|undefined reference to `cURLpp::Easy::~Easy()'\| obj\Release\downloads\curlpp\curlpp- 0.7.2\examples\example22.o:example22.cpp:(.text+0x2cd)\|\|undefined reference to `__imp___ZN6cURLpp7CleanupD1Ev'\| obj\Release\downloads\curlpp\curlpp- 0.7.2\examples\example22.o:example22.cpp:(.text+0x43f)\|\|undefined reference to `cURLpp::Easy::~Easy()'\| obj\Release\downloads\curlpp\curlpp- 0.7.2\examples\example22.o:example22.cpp:(.text+0x44c)\|\|undefined reference to `__imp___ZN6cURLpp7CleanupD1Ev'\| ]+0x10)\|\|undefined reference to `cURLpp::OptionBase::operator<(cURLpp::OptionBase const&) const'\| ]+0x10)\|\|undefined reference to `cURLpp::OptionBase::operator<(cURLpp::OptionBase const&) const'\| ::~Option()]+0x7d)\|\|undefined reference to `__imp___ZN6cURLpp10OptionBaseD2Ev'\| ::~Option()]+0xf4)\|\|undefined reference to `__imp___ZN6cURLpp10OptionBaseD2Ev'\| ::~Option()]+0x7d)\|\|undefined reference to `__imp___ZN6cURLpp10OptionBaseD2Ev'\| ::~Option()]+0xe9)\|\|undefined reference to `__imp___ZN6cURLpp10OptionBaseD2Ev'\| ::~Option()]+0x7d)\|\|undefined reference to `__imp___ZN6cURLpp10OptionBaseD2Ev'\| obj\Release\downloads\curlpp\curlpp- 0.7.2\examples\example22.o:example22.cpp:(.text$_ZN6cURLpp11UnsetOptionD1Ev[cURLpp::U nsetOption::~UnsetOption()]+0x14)\|\|undefined reference to `__imp___ZN6cURLpp12RuntimeErrorD2Ev'\| obj\Release\downloads\curlpp\curlpp- 0.7.2\examples\example22.o:example22.cpp:(.text$_ZN6cURLpp11UnsetOptionD0Ev[cURLpp::U nsetOption::~UnsetOption()]+0x15)\|\|undefined reference to `__imp___ZN6cURLpp12RuntimeErrorD2Ev'\| ::getValue() const]+0x84)\|\|undefined reference to `__imp___ZN6cURLpp11UnsetOptionC1ERKSs'\| )]+0x53)\|\|undefined reference to `__imp___ZN6cURLpp10OptionBaseC2E10CURLoption'\| )]+0xb7)\|\|undefined reference to `__imp___ZN6cURLpp10OptionBaseD2Ev'\| )]+0x128)\|\|undefined reference to `__imp___ZN6cURLpp11UnsetOptionC1EPKc'\| )]+0x2f)\|\|undefined reference to `__imp___ZN6cURLpp20libcurlRuntimeAssertEPKc8CURLcode'\| ) const]+0x84)\|\|undefined reference to `__imp___ZN6cURLpp11UnsetOptionC1ERKSs'\| \|\|=== Build finished: 24 errors, 0 warnings ===\| I am getting linker issue in code::blocks obj\Release\downloads\curlpp\curlpp- 0.7.2\examples\example22.o:example22.cpp:(.text+0x11f)\|\|undefined reference to `__imp___ZN6cURLpp7CleanupC1Ev'\| obj\Release\downloads\curlpp\curlpp- 0.7.2\examples\example22.o:example22.cpp:(.text+0x131)\|\|undefined reference to `__imp___ZN6cURLpp4EasyC1Ev'\| obj\Release\downloads\curlpp\curlpp- 0.7.2\examples\example22.o:example22.cpp:(.text+0x1bd)\|\|undefined reference to `cURLpp::Easy::setOpt(cURLpp::OptionBase)'\| obj\Release\downloads\curlpp\curlpp- 0.7.2\examples\example22.o:example22.cpp:(.text+0x1f3)\|\|undefined reference to `operator<<(std::ostream&, cURLpp::Easy const&)'\| obj\Release\downloads\curlpp\curlpp- 0.7.2\examples\example22.o:example22.cpp:(.text+0x263)\|\|undefined reference to `operator<<(std::ostream&, cURLpp::OptionTrait<std::string, (CURLoption)10002> const&)'\| obj\Release\downloads\curlpp\curlpp- 0.7.2\examples\example22.o:example22.cpp:(.text+0x2bd)\|\|undefined reference to `cURLpp::Easy::~Easy()'\| obj\Release\downloads\curlpp\curlpp- 0.7.2\examples\example22.o:example22.cpp:(.text+0x2cd)\|\|undefined reference to `__imp___ZN6cURLpp7CleanupD1Ev'\| obj\Release\downloads\curlpp\curlpp- 0.7.2\examples\example22.o:example22.cpp:(.text+0x43f)\|\|undefined reference to `cURLpp::Easy::~Easy()'\| obj\Release\downloads\curlpp\curlpp- 0.7.2\examples\example22.o:example22.cpp:(.text+0x44c)\|\|undefined reference to `__imp___ZN6cURLpp7CleanupD1Ev'\| ]+0x10)\|\|undefined reference to `cURLpp::OptionBase::operator<(cURLpp::OptionBase const&) const'\| ]+0x10)\|\|undefined reference to `cURLpp::OptionBase::operator<(cURLpp::OptionBase const&) const'\| ::~Option()]+0x7d)\|\|undefined reference to `__imp___ZN6cURLpp10OptionBaseD2Ev'\| ::~Option()]+0xf4)\|\|undefined reference to `__imp___ZN6cURLpp10OptionBaseD2Ev'\| ::~Option()]+0x7d)\|\|undefined reference to `__imp___ZN6cURLpp10OptionBaseD2Ev'\| ::~Option()]+0xe9)\|\|undefined reference to `__imp___ZN6cURLpp10OptionBaseD2Ev'\| ::~Option()]+0x7d)\|\|undefined reference to `__imp___ZN6cURLpp10OptionBaseD2Ev'\| obj\Release\downloads\curlpp\curlpp- 0.7.2\examples\example22.o:example22.cpp:(.text$_ZN6cURLpp11UnsetOptionD1Ev[cURLpp::U nsetOption::~UnsetOption()]+0x14)\|\|undefined reference to `__imp___ZN6cURLpp12RuntimeErrorD2Ev'\| obj\Release\downloads\curlpp\curlpp- 0.7.2\examples\example22.o:example22.cpp:(.text$_ZN6cURLpp11UnsetOptionD0Ev[cURLpp::U nsetOption::~UnsetOption()]+0x15)\|\|undefined reference to `__imp___ZN6cURLpp12RuntimeErrorD2Ev'\| ::getValue() const]+0x84)\|\|undefined reference to `__imp___ZN6cURLpp11UnsetOptionC1ERKSs'\| )]+0x53)\|\|undefined reference to `__imp___ZN6cURLpp10OptionBaseC2E10CURLoption'\| )]+0xb7)\|\|undefined reference to `__imp___ZN6cURLpp10OptionBaseD2Ev'\| )]+0x128)\|\|undefined reference to `__imp___ZN6cURLpp11UnsetOptionC1EPKc'\| )]+0x2f)\|\|undefined reference to `__imp___ZN6cURLpp20libcurlRuntimeAssertEPKc8CURLcode'\| ) const]+0x84)\|\|undefined reference to `__imp___ZN6cURLpp11UnsetOptionC1ERKSs'\| \|\|=== Build finished: 24 errors, 0 warnings ===\| Oct 21, 2009 issue 16 (Compile issue on MingW) reported by dwmcqueen - What steps will reproduce the problem? 1. ./configure --with-boost=/c/Tools/boost --disable-shared --disable-ewarning -prefix=/mingw Produces the following: checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether ln -s works... yes checking whether make sets $(MAKE)... (cached) yes checking for gcc... gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking for a BSD-compatible install... /bin/install -c checking how to run the C++ preprocessor... g++ -E checking for a sed that does not truncate output... /bin/sed checking for Boost headers version >= 0... /c/Tools/boost/include/boost-1_40 checking for Boost's header version... 1_40 checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ld used by gcc... c:/mingw/mingw32/bin/ld.exe checking if the linker (c:/mingw/mingw32/bin/ld.exe) is GNU ld... yes checking for c:/mingw/mingw32/bin/ld.exe option to reload object files... -r checking for BSD-compatible nm... /mingw/bin/nm checking how to recognise dependent libraries... file_magic file format pei-i386(.architecture: i386)? checking for dlltool... dlltool checking for as... as checking for objdump... objdump checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... no checking dlfcn.h presence... no checking for dlfcn.h... no checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for xlf95... no checking for f95... no checking for fort... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 8192 checking command to parse /mingw/bin/nm output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -DDLL_EXPORT checking if gcc PIC flag -DDLL_EXPORT works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (c:/mingw/mingw32/bin/ld.exe) supports shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... no checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... c:/mingw/mingw32/bin/ld.exe checking if the linker (c:/mingw/mingw32/bin/ld.exe) is GNU ld... yes checking whether the g++ linker (c:/mingw/mingw32/bin/ld.exe) supports shared libraries... yes checking for g++ option to produce PIC... -DDLL_EXPORT checking if g++ PIC flag -DDLL_EXPORT works... yes checking if g++ static flag -static works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (c:/mingw/mingw32/bin/ld.exe) supports shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking for ANSI C header files... (cached) yes checking curl/curl.h usability... yes checking curl/curl.h presence... yes checking for curl/curl.h... yes checking ostream usability... yes checking ostream presence... yes checking for ostream... yes checking for curl >= 7.10.0... 7.19.6 checking enable gcc warnings... yes checking warning make an error on compilation... no checking whether to enable the maintener code... no checking whether to enable Debug symbols support options... no checking if we need BUILDING_CURLPP... yes checking if we need CURLPP_STATICLIB... yes configure: creating ./config.status config.status: creating curlpp-config config.status: creating curlpp.spec config.status: creating curlpp.pc config.status: creating Makefile config.status: creating examples/Makefile config.status: creating src/Makefile config.status: creating src/curlpp/Makefile config.status: creating src/curlpp/internal/Makefile config.status: creating src/utilspp/Makefile config.status: creating include/Makefile config.status: creating include/curlpp/Makefile config.status: creating include/curlpp/internal/Makefile config.status: creating include/utilspp/Makefile config.status: creating include/utilspp/functor/Makefile config.status: creating include/utilspp/singleton/Makefile config.status: creating doc/Makefile config.status: creating include/curlpp/config.h config.status: include/curlpp/config.h is unchanged config.status: executing depfiles commands 2. make - see a lot of warnings like warning: 'curlpp::internal::SList::SList(const curlpp::internal::SList&)' redeclared without dllimport attribute: previous dllimport ignored in attached file2.txt What is the expected output? What do you see instead? compilation, but instead see linker errors What version of the product are you using? On what operating system? Please provide any additional information below. What steps will reproduce the problem? 1. ./configure --with-boost=/c/Tools/boost --disable-shared --disable-ewarning -prefix=/mingw Produces the following: checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether ln -s works... yes checking whether make sets $(MAKE)... (cached) yes checking for gcc... gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking for a BSD-compatible install... /bin/install -c checking how to run the C++ preprocessor... g++ -E checking for a sed that does not truncate output... /bin/sed checking for Boost headers version >= 0... /c/Tools/boost/include/boost-1_40 checking for Boost's header version... 1_40 checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ld used by gcc... c:/mingw/mingw32/bin/ld.exe checking if the linker (c:/mingw/mingw32/bin/ld.exe) is GNU ld... yes checking for c:/mingw/mingw32/bin/ld.exe option to reload object files... -r checking for BSD-compatible nm... /mingw/bin/nm checking how to recognise dependent libraries... file_magic file format pei-i386(.architecture: i386)? checking for dlltool... dlltool checking for as... as checking for objdump... objdump checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... no checking dlfcn.h presence... no checking for dlfcn.h... no checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for xlf95... no checking for f95... no checking for fort... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 8192 checking command to parse /mingw/bin/nm output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -DDLL_EXPORT checking if gcc PIC flag -DDLL_EXPORT works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (c:/mingw/mingw32/bin/ld.exe) supports shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... no checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... c:/mingw/mingw32/bin/ld.exe checking if the linker (c:/mingw/mingw32/bin/ld.exe) is GNU ld... yes checking whether the g++ linker (c:/mingw/mingw32/bin/ld.exe) supports shared libraries... yes checking for g++ option to produce PIC... -DDLL_EXPORT checking if g++ PIC flag -DDLL_EXPORT works... yes checking if g++ static flag -static works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (c:/mingw/mingw32/bin/ld.exe) supports shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking for ANSI C header files... (cached) yes checking curl/curl.h usability... yes checking curl/curl.h presence... yes checking for curl/curl.h... yes checking ostream usability... yes checking ostream presence... yes checking for ostream... yes checking for curl >= 7.10.0... 7.19.6 checking enable gcc warnings... yes checking warning make an error on compilation... no checking whether to enable the maintener code... no checking whether to enable Debug symbols support options... no checking if we need BUILDING_CURLPP... yes checking if we need CURLPP_STATICLIB... yes configure: creating ./config.status config.status: creating curlpp-config config.status: creating curlpp.spec config.status: creating curlpp.pc config.status: creating Makefile config.status: creating examples/Makefile config.status: creating src/Makefile config.status: creating src/curlpp/Makefile config.status: creating src/curlpp/internal/Makefile config.status: creating src/utilspp/Makefile config.status: creating include/Makefile config.status: creating include/curlpp/Makefile config.status: creating include/curlpp/internal/Makefile config.status: creating include/utilspp/Makefile config.status: creating include/utilspp/functor/Makefile config.status: creating include/utilspp/singleton/Makefile config.status: creating doc/Makefile config.status: creating include/curlpp/config.h config.status: include/curlpp/config.h is unchanged config.status: executing depfiles commands 2. make - see a lot of warnings like warning: 'curlpp::internal::SList::SList(const curlpp::internal::SList&)' redeclared without dllimport attribute: previous dllimport ignored in attached file2.txt What is the expected output? What do you see instead? compilation, but instead see linker errors What version of the product are you using? On what operating system? Please provide any additional information below. Sep 23, 2009 issue 15 (Make fails) reported by actorzach - What steps will reproduce the problem? 1. ./configure 2. make What is the expected output? What do you see instead? what I got: zach@zach-laptop:~/curlpp$ make make: * No targets specified and no makefile found. Stop. What version of the product are you using? On what operating system? using version 0.7.2 on ubuntu linux jaunty Please provide any additional information below. What steps will reproduce the problem? 1. ./configure 2. make What is the expected output? What do you see instead? what I got: zach@zach-laptop:~/curlpp$ make make: * No targets specified and no makefile found. Stop. What version of the product are you using? On what operating system? using version 0.7.2 on ubuntu linux jaunty Please provide any additional information below. Aug 07, 2009 Compilers Wiki page commented on by djzmoo - However, Microsoft Visual C++ 2008 Express Edition is totally free and no licenses are necessary. However, Microsoft Visual C++ 2008 Express Edition is totally free and no licenses are necessary. Jul 17, 2009 issue 14 (Can't build) commented on by a...@potatoriot.com - This is fixed by adding these includes: #include <algorithm> to LifetimeWithLongevity.hpp #include <string.h> to CurlHandle.hpp #include <cstdlib> to cURLpp.hpp As explained on the mailing list http://groups.google.com/group/curlpp/browse_thread/thread/e3df334f0737040e?hl=en This is fixed by adding these includes: #include <algorithm> to LifetimeWithLongevity.hpp #include <string.h> to CurlHandle.hpp #include <cstdlib> to cURLpp.hpp As explained on the mailing list http://groups.google.com/group/curlpp/browse_thread/thread/e3df334f0737040e?hl=en Jul 12, 2009 issue 14 (Can't build) reported by painejake - What steps will reproduce the problem? 1. ./configure 2. make What is the expected output? What do you see instead? Output is: then mv -f ".deps/LifetimeLibrary.Tpo" ".deps/LifetimeLibrary.Plo"; else rm -f ".deps/LifetimeLibrary.Tpo"; exit 1; fi In file included from LifetimeWithLongevity.hpp:54, from SingletonHolder.hpp:31, from LifetimeLibrary.cpp:1: LifetimeWithLongevity.inl: In function 'void utilspp::setLongevity(T, unsigned int, TDestroyer)': LifetimeWithLongevity.inl:19: error: 'upper_bound' is not a member of 'std' LifetimeLibrary.cpp: In member function 'void utilspp::LifetimeLibraryImpl::add(utilspp::PrivateMembers::LifetimeTracker)': LifetimeLibrary.cpp:29: error: 'upper_bound' is not a member of 'std' make[2]: * [LifetimeLibrary.lo] Error 1 make[2]: Leaving directory `/home/jake/Desktop/curlpp-0.7.2/utilspp/singleton' make[1]: * [all-recursive] Error 1 make[1]: Leaving directory `/home/jake/Desktop/curlpp-0.7.2/utilspp' make: *** [all-recursive] Error 1 jake@desktop:~/Desktop/curlpp-0.7.2$ What version of the product are you using? On what operating system? Ubuntu 9.04 x86_64 - curlpp-0.7.2 - GCC 4.3 What steps will reproduce the problem? 1. ./configure 2. make What is the expected output? What do you see instead? Output is: then mv -f ".deps/LifetimeLibrary.Tpo" ".deps/LifetimeLibrary.Plo"; else rm -f ".deps/LifetimeLibrary.Tpo"; exit 1; fi In file included from LifetimeWithLongevity.hpp:54, from SingletonHolder.hpp:31, from LifetimeLibrary.cpp:1: LifetimeWithLongevity.inl: In function 'void utilspp::setLongevity(T, unsigned int, TDestroyer)': LifetimeWithLongevity.inl:19: error: 'upper_bound' is not a member of 'std' LifetimeLibrary.cpp: In member function 'void utilspp::LifetimeLibraryImpl::add(utilspp::PrivateMembers::LifetimeTracker)': LifetimeLibrary.cpp:29: error: 'upper_bound' is not a member of 'std' make[2]: * [LifetimeLibrary.lo] Error 1 make[2]: Leaving directory `/home/jake/Desktop/curlpp-0.7.2/utilspp/singleton' make[1]: * [all-recursive] Error 1 make[1]: Leaving directory `/home/jake/Desktop/curlpp-0.7.2/utilspp' make: * [all-recursive] Error 1 jake@desktop:~/Desktop/curlpp-0.7.2$ What version of the product are you using? On what operating system? Ubuntu 9.04 x86_64 - curlpp-0.7.2 - GCC 4.3 Jun 19, 2009 issue 13 (Wrong option type - FtpResponseTimeout) reported by saddan0 - There's a problem on the type of FtpResponseTimeout. Options.hpp declares this: typedef cURLpp::OptionTrait< bool, CURLOPT_FTP_RESPONSE_TIMEOUT > FtpResponseTimeout; but the timeout should be a long. So, using easy.setOpt(new cURLpp::Options::FtpResponseTimeout(timeout)); compiles but the timeout is ignored. Using directly the curl handler works perfectly: curl_easy_setopt(easy.getHandle(), CURLOPT_FTP_RESPONSE_TIMEOUT, timeout); curl_easy_perform(easy.getHandle()); I'm using version 0.7.2, but the latest version available 0.7.3-pre2 has the same problem. Regards, Guilherme There's a problem on the type of FtpResponseTimeout. Options.hpp declares this: typedef cURLpp::OptionTrait< bool, CURLOPT_FTP_RESPONSE_TIMEOUT > FtpResponseTimeout; but the timeout should be a long. So, using easy.setOpt(new cURLpp::Options::FtpResponseTimeout(timeout)); compiles but the timeout is ignored. Using directly the curl handler works perfectly: curl_easy_setopt(easy.getHandle(), CURLOPT_FTP_RESPONSE_TIMEOUT, timeout); curl_easy_perform(easy.getHandle()); I'm using version 0.7.2, but the latest version available 0.7.3-pre2 has the same problem. Regards, Guilherme Jun 05, 2009 issue 12 (example 11 compile error) reported by vtians - What steps will reproduce the problem? 1. ./configure 2. make 3. What is the expected output? What do you see instead? Console output: g++ -DHAVE_CONFIG_H -I. -I../include/curlpp -I../include -g -W -Wall -Werror -MT example11.o -MD -MP -MF .deps/example11.Tpo -c -o example11.o example11.cpp cc1plus: warnings being treated as errors example11.cpp: In function ‘int main(int, char)’: example11.cpp:81: error: format not a string literal and no format arguments make[1]: * [example11.o] Error 1 make[1]: Leaving directory `/try/curlpp/curlpp-0.7.3-pre2/examples' make: * [all-recursive] Error 1 What version of the product are you using? On what operating system? curlpp-0.7.3-pre2 On Ubuntu 8.10 gcc 4.3.2 Please provide any additional information below. The related line in source code: fprintf(stderr, strerror(errno)); What steps will reproduce the problem? 1. ./configure 2. make 3. What is the expected output? What do you see instead? Console output: g++ -DHAVE_CONFIG_H -I. -I../include/curlpp -I../include -g -W -Wall -Werror -MT example11.o -MD -MP -MF .deps/example11.Tpo -c -o example11.o example11.cpp cc1plus: warnings being treated as errors example11.cpp: In function ‘int main(int, char)’: example11.cpp:81: error: format not a string literal and no format arguments make[1]: * [example11.o] Error 1 make[1]: Leaving directory `/try/curlpp/curlpp-0.7.3-pre2/examples' make: *** [all-recursive] Error 1 What version of the product are you using? On what operating system? curlpp-0.7.3-pre2 On Ubuntu 8.10 gcc 4.3.2 Please provide any additional information below. The related line in source code: fprintf(stderr, strerror(errno)); Jun 04, 2009 issue 11 (Example 19 could be clearer) reported by cquezel - In example 19, I think the following lines: std::ofstream myfile("/dev/null"); myfile << request << std::endl << request << std::endl; Could be replaced by: request.perform(); and make the example clearer (and possibly correct though I'm not sure the original is incorrect). In example 19, I think the following lines: std::ofstream myfile("/dev/null"); myfile << request << std::endl << request << std::endl; Could be replaced by: request.perform(); and make the example clearer (and possibly correct though I'm not sure the original is incorrect). May 28, 2009 issue 10 (There is probably a logic error in buildconfig.h) reported by cquezel - In curlpp-0.7.3-pre2 the if and else clause are identical: #if defined(BUILDING_CURLPP) #define CURLPP_INCLUDE_TEMPLATE_DEFINITIONS #undef CURLPP_TEMPLATE_EXPLICIT_INSTANTIATION #else #define CURLPP_INCLUDE_TEMPLATE_DEFINITIONS #undef CURLPP_TEMPLATE_EXPLICIT_INSTANTIATION #endif In curlpp-0.7.3-pre2 the if and else clause are identical: #if defined(BUILDING_CURLPP) #define CURLPP_INCLUDE_TEMPLATE_DEFINITIONS #undef CURLPP_TEMPLATE_EXPLICIT_INSTANTIATION #else #define CURLPP_INCLUDE_TEMPLATE_DEFINITIONS #undef CURLPP_TEMPLATE_EXPLICIT_INSTANTIATION #endif May 28, 2009 issue 9 (VC9 project contains invalid references) reported by cquezel - In the generated VC9 project, the references to: .\src\utilspp\singleton\PrivateMembers.cpp .\src\utilspp\singleton\LifetimeLibrary.cpp Should be: .\src\utilspp\PrivateMembers.cpp .\src\utilspp\LifetimeLibrary.cpp (or the files should be moved) The reference to .\src\curlpp\Infos.cpp (and) .\src\curlpp\Option.cpp do not exist. In the generated VC9 project, the references to: .\src\utilspp\singleton\PrivateMembers.cpp .\src\utilspp\singleton\LifetimeLibrary.cpp Should be: .\src\utilspp\PrivateMembers.cpp .\src\utilspp\LifetimeLibrary.cpp (or the files should be moved) The reference to .\src\curlpp\Infos.cpp (and) .\src\curlpp\Option.cpp do not exist. May 28, 2009 issue 8 (VC9 solution script generates incorrect names) reported by cquezel - If I extract curlpp-0.7.3-pre2 and go to the win32 directory and run the “create-vc-solution.bat 9” and the try to load the generated project I get the following 2 errors: Project file ‘…\curlpp-0.7.3-pre2\curlpp.VC9.vcproj’ could not be loaded. Project file ‘…\curlpp-0.7.3-pre2\curlpp.examples.VC9.vcproj’ could not be loaded. That’s because the generated files are not named that way. If I try to load the generated files instead I get more errors because they refer to names with different names. The fix I used is to rename the generated files as: Curlpp.lib.vsprops -> Curlpp.VC9.vsprops (note the lib is gone) Curlpp.lib.vcproj -> Curlpp.VC9.vproj (note the lib is gone) Curlpp.common.vsprops -> Curlpp.common.VC9.vsprops Curlpp.examples.vcproj -> Curlpp.examples.VC9.vcproj Curlpp.examples.vsprops -> Curlpp.examples.VC9.vsprops I also renamed (for symmetry only) Curlpp.sln -> Curlpp.VC9.sln If I extract curlpp-0.7.3-pre2 and go to the win32 directory and run the “create-vc-solution.bat 9” and the try to load the generated project I get the following 2 errors: Project file ‘…\curlpp-0.7.3-pre2\curlpp.VC9.vcproj’ could not be loaded. Project file ‘…\curlpp-0.7.3-pre2\curlpp.examples.VC9.vcproj’ could not be loaded. That’s because the generated files are not named that way. If I try to load the generated files instead I get more errors because they refer to names with different names. The fix I used is to rename the generated files as: Curlpp.lib.vsprops -> Curlpp.VC9.vsprops (note the lib is gone) Curlpp.lib.vcproj -> Curlpp.VC9.vproj (note the lib is gone) Curlpp.common.vsprops -> Curlpp.common.VC9.vsprops Curlpp.examples.vcproj -> Curlpp.examples.VC9.vcproj Curlpp.examples.vsprops -> Curlpp.examples.VC9.vsprops I also renamed (for symmetry only) Curlpp.sln -> Curlpp.VC9.sln May 23, 2009 curlpp-0.7.3-pre2.tar.gz (latest devel version) file uploaded by jpbarrette - Labels: Featured Type-Source OpSys-All Labels: Featured Type-Source OpSys-All May 22, 2009 curlpp-0.7.3-pre1.tar.gz (latest devel version) file uploaded by jpbarrette May 21, 2009 curlpp-current.2009.05.21.zip (curlpp-current.2009.05.21) file uploaded by p...@1.google.dobrogost.pl Feb 20, 2009 libcurlMDd.zip (libcurl win32 binaries (uses: dynamic OpenSSL, dynamic zlib,...) file uploaded by p...@1.google.autoera.pl Feb 20, 2009 libcurlMD.zip (libcurl win32 binaries (uses: dynamic OpenSSL, dynamic zlib,...) file uploaded by p...@1.google.autoera.pl Feb 20, 2009 curlppMDd.zip (cURL++ win32 binaries (dynamic libcurl, dynamic RTL, debug v...) file uploaded by p...@1.google.autoera.pl Feb 20, 2009 curlppMD.zip (cURL++ win32 binaries (dynamic libcurl, dynamic RTL)) file uploaded by p...@1.google.autoera.pl Feb 15, 2009 curlpp-current.2009-02-16.zip (latest devel version (2009.02.16)) file uploaded by p...@google.1.2009.autoera.pl Feb 13, 2009 Compilers Wiki page edited by jpbarrette Feb 13, 2009 Compilers Wiki page added by jpbarrette Feb 13, 2009 DevelopmentPlans Wiki page added by jpbarrette Feb 13, 2009 CodeHistory Wiki page edited by jpbarrette Feb 13, 2009 CodeHistory Wiki page edited by jpbarrette Feb 13, 2009 CodeHistory (cURLpp Development Plans) Wiki page added by jpbarrette Feb 13, 2009 News Wiki page deleted by jpbarrette Feb 01, 2009 curlpp-0.7.2.tar.gz (last stable version) file uploaded by jpbarrette - Labels: Type-Source OpSys-All Featured Labels: Type-Source OpSys-All Featured Feb 01, 2009 News Wiki page added by jpbarrette Jan 31, 2009 issue 7 (QA for curlpp) reported by and...@korostelev.net - Introduce (unit) tests for curlpp. The use cases for tests can be largely taken from examples. Introduce (unit) tests for curlpp. The use cases for tests can be largely taken from examples. Jan 20, 2009 issue 5 (gnu tools boost detection doesn't work properly) reported by jpbarrette - the current M4 script isn't able to detect well installed boost libraries. the current M4 script isn't able to detect well installed boost libraries.

issue 21 (Callbacks created on stack should be disabled when leaving t...) reported by terrade...@gmail.com - Using latest curlpp with latest libcurl, on debian lenny. I am using curlpp Write and WriteHeader callbacks by creating their objects on the stack and then setting the options in the Easy curlpp object. However the Easy object itself is created somewhere outside the function when callbacks are set, it is used for persistent connections. All the request options are reset for each request for the same Easy object. Usually I have http requests and the design works without any problem. But then I had some ftp request coming through my application. At some point the connection was about to be closed, and it resulted in some "Good bye" ftp header received, and a crash with the following stack: 0x00000005 in ?? () #1 0xa50905cb in myapp::WriteHeaderCallback::WriteHeaderCallbackFunction (this=0xef1d6980, ptr=0x64bed5dc "221 Goodbye.\r\nompleted.\r", size=1, nmemb=14) at myapp/myapp.cpp:312 #2 0xa506e5f1 in utilspp::MemFunHandler<utilspp::Functor<unsigned int, utilspp::tl::TypeList<char*, utilspp::tl::TypeList<unsigned int, utilspp::tl::TypeList<unsigned int, utilspp::NullType> > > >, myapp::WriteHeaderCallback*, unsigned int (myapp::WriteHeaderCallback::*)(char*, unsigned int, unsigned int)>::operator() (this=0xb285abb8, p1=0x64bed5dc "221 Goodbye.\r\nompleted.\r", p2=1, p3=14) at /usr/include/utilspp/functor/MemFunHandler.hpp:55 #3 0xe412f86d in utilspp::Functor<unsigned int, utilspp::tl::TypeList<char*, utilspp::tl::TypeList<unsigned int, utilspp::tl::TypeList<unsigned int, utilspp::NullType> > > >::operator() (this=0x64bf5920, p1=0x64bed5dc "221 Goodbye.\r\nompleted.\r", p2=1, p3=14) at ../../../include/utilspp/functor/Functor.hpp:106 #4 0xe412e370 in curlpp::internal::CurlHandle::executeHeaderFunctor (this=0x64bf5810, buffer=0x64bed5dc "221 Goodbye.\r\nompleted.\r", size=1, nitems=14) at CurlHandle.cpp:199 #5 0xe4135673 in curlpp::internal::Callbacks::HeaderCallback (buffer=0x64bed5dc "221 Goodbye.\r\nompleted.\r", size=1, nitems=14, handle=0x64bf5810) at OptionSetter.cpp:66 #6 0xf711c398 in Curl_client_write (conn=0xbae6a094, type=<value optimized out>, ptr=0x64bed5dc "221 Goodbye.\r\nompleted.\r", len=14) at sendf.c:489 #7 0xf7150882 in Curl_pp_readresp (sockfd=87, pp=0xbae6a444, code=0xef1d7648, size=0xef1d7740) at pingpong.c:398 #8 0xf711d1af in ftp_readresp (sockfd=-1525497406, pp=0xef1d6984, ftpcode=0xef1d7744, size=0xef1d7740) at ftp.c:401 #9 0xf711f94b in ftp_statemach_act (conn=0xbae6a094) at ftp.c:2406 #10 0xf7150feb in Curl_pp_easy_statemach (pp=0xbae6a444) at pingpong.c:154 #11 0xf711ca6e in ftp_disconnect (conn=0xbae6a094, dead_connection=false) at ftp.c:2831 #12 0xf71241d9 in Curl_disconnect (conn=0xbae6a094, dead_connection=194) at url.c:2650 #13 0xf7124c57 in ConnectionKillOne (data=0x64bed11c) at url.c:3101 #14 0xf71290ef in Curl_close (data=0x64bed11c) at url.c:279 #15 0xf7136e41 in curl_easy_cleanup (curl=0xa512c1c2) at easy.c:582 #16 0xe412e783 in ~CurlHandle (this=0x64bf5810) at CurlHandle.cpp:110 #17 0xa506d6d7 in ~auto_ptr (this=0xb773476c) at /usr/include/c++/4.3/backward/auto_ptr.h:173 #18 0xe4126998 in ~Easy (this=0xb7734768) at Easy.cpp:42 The thing is that this was called outside the function that instantiates my WriteHeaderCallback, so there is nothing surprising that everything ended up with a crash. I don't think that this is an extraordinary situation, when the Easy object is reused for multiple requests. But now I realize, that some options should be reset if they are created using the stack objects and they are leaving the stack. Some options are probably harmless, they simply set some libcurl flags, however callbacks are dangerous to leave and they should be reset explicitly. The alternative might be to use static callbacks object, or allocate them dynamically, however they both would result in even more difficult problems (synchronization, or questions when to deallocate dynamic object). The current idea of allocating callbacks and functors on the stack is good enough most of the time. I think the solution is to reset libcurl callback options in the destructor of curlpp callback objects. For now I will try to reset the curl options using the libcurl C API in that specific function of mine, however I am looking forward to a proper solution in curlpp.

Using latest curlpp with latest libcurl, on debian lenny. I am using curlpp Write and WriteHeader callbacks by creating their objects on the stack and then setting the options in the Easy curlpp object. However the Easy object itself is created somewhere outside the function when callbacks are set, it is used for persistent connections. All the request options are reset for each request for the same Easy object. Usually I have http requests and the design works without any problem. But then I had some ftp request coming through my application. At some point the connection was about to be closed, and it resulted in some "Good bye" ftp header received, and a crash with the following stack: 0x00000005 in ?? () #1 0xa50905cb in myapp::WriteHeaderCallback::WriteHeaderCallbackFunction (this=0xef1d6980, ptr=0x64bed5dc "221 Goodbye.\r\nompleted.\r", size=1, nmemb=14) at myapp/myapp.cpp:312 #2 0xa506e5f1 in utilspp::MemFunHandler<utilspp::Functor<unsigned int, utilspp::tl::TypeList<char*, utilspp::tl::TypeList<unsigned int, utilspp::tl::TypeList<unsigned int, utilspp::NullType> > > >, myapp::WriteHeaderCallback*, unsigned int (myapp::WriteHeaderCallback::*)(char*, unsigned int, unsigned int)>::operator() (this=0xb285abb8, p1=0x64bed5dc "221 Goodbye.\r\nompleted.\r", p2=1, p3=14) at /usr/include/utilspp/functor/MemFunHandler.hpp:55 #3 0xe412f86d in utilspp::Functor<unsigned int, utilspp::tl::TypeList<char*, utilspp::tl::TypeList<unsigned int, utilspp::tl::TypeList<unsigned int, utilspp::NullType> > > >::operator() (this=0x64bf5920, p1=0x64bed5dc "221 Goodbye.\r\nompleted.\r", p2=1, p3=14) at ../../../include/utilspp/functor/Functor.hpp:106 #4 0xe412e370 in curlpp::internal::CurlHandle::executeHeaderFunctor (this=0x64bf5810, buffer=0x64bed5dc "221 Goodbye.\r\nompleted.\r", size=1, nitems=14) at CurlHandle.cpp:199 #5 0xe4135673 in curlpp::internal::Callbacks::HeaderCallback (buffer=0x64bed5dc "221 Goodbye.\r\nompleted.\r", size=1, nitems=14, handle=0x64bf5810) at OptionSetter.cpp:66 #6 0xf711c398 in Curl_client_write (conn=0xbae6a094, type=<value optimized out>, ptr=0x64bed5dc "221 Goodbye.\r\nompleted.\r", len=14) at sendf.c:489 #7 0xf7150882 in Curl_pp_readresp (sockfd=87, pp=0xbae6a444, code=0xef1d7648, size=0xef1d7740) at pingpong.c:398 #8 0xf711d1af in ftp_readresp (sockfd=-1525497406, pp=0xef1d6984, ftpcode=0xef1d7744, size=0xef1d7740) at ftp.c:401 #9 0xf711f94b in ftp_statemach_act (conn=0xbae6a094) at ftp.c:2406 #10 0xf7150feb in Curl_pp_easy_statemach (pp=0xbae6a444) at pingpong.c:154 #11 0xf711ca6e in ftp_disconnect (conn=0xbae6a094, dead_connection=false) at ftp.c:2831 #12 0xf71241d9 in Curl_disconnect (conn=0xbae6a094, dead_connection=194) at url.c:2650 #13 0xf7124c57 in ConnectionKillOne (data=0x64bed11c) at url.c:3101 #14 0xf71290ef in Curl_close (data=0x64bed11c) at url.c:279 #15 0xf7136e41 in curl_easy_cleanup (curl=0xa512c1c2) at easy.c:582 #16 0xe412e783 in ~CurlHandle (this=0x64bf5810) at CurlHandle.cpp:110 #17 0xa506d6d7 in ~auto_ptr (this=0xb773476c) at /usr/include/c++/4.3/backward/auto_ptr.h:173 #18 0xe4126998 in ~Easy (this=0xb7734768) at Easy.cpp:42 The thing is that this was called outside the function that instantiates my WriteHeaderCallback, so there is nothing surprising that everything ended up with a crash. I don't think that this is an extraordinary situation, when the Easy object is reused for multiple requests. But now I realize, that some options should be reset if they are created using the stack objects and they are leaving the stack. Some options are probably harmless, they simply set some libcurl flags, however callbacks are dangerous to leave and they should be reset explicitly. The alternative might be to use static callbacks object, or allocate them dynamically, however they both would result in even more difficult problems (synchronization, or questions when to deallocate dynamic object). The current idea of allocating callbacks and functors on the stack is good enough most of the time. I think the solution is to reset libcurl callback options in the destructor of curlpp callback objects. For now I will try to reset the curl options using the libcurl C API in that specific function of mine, however I am looking forward to a proper solution in curlpp.

issue 16 (Compile issue on MingW) reported by dwmcqueen - What steps will reproduce the problem? 1. ./configure --with-boost=/c/Tools/boost --disable-shared --disable-ewarning -prefix=/mingw Produces the following: checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether ln -s works... yes checking whether make sets $(MAKE)... (cached) yes checking for gcc... gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking for a BSD-compatible install... /bin/install -c checking how to run the C++ preprocessor... g++ -E checking for a sed that does not truncate output... /bin/sed checking for Boost headers version >= 0... /c/Tools/boost/include/boost-1_40 checking for Boost's header version... 1_40 checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ld used by gcc... c:/mingw/mingw32/bin/ld.exe checking if the linker (c:/mingw/mingw32/bin/ld.exe) is GNU ld... yes checking for c:/mingw/mingw32/bin/ld.exe option to reload object files... -r checking for BSD-compatible nm... /mingw/bin/nm checking how to recognise dependent libraries... file_magic file format pei*-i386(.*architecture: i386)? checking for dlltool... dlltool checking for as... as checking for objdump... objdump checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... no checking dlfcn.h presence... no checking for dlfcn.h... no checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for xlf95... no checking for f95... no checking for fort... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 8192 checking command to parse /mingw/bin/nm output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -DDLL_EXPORT checking if gcc PIC flag -DDLL_EXPORT works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (c:/mingw/mingw32/bin/ld.exe) supports shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... no checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... c:/mingw/mingw32/bin/ld.exe checking if the linker (c:/mingw/mingw32/bin/ld.exe) is GNU ld... yes checking whether the g++ linker (c:/mingw/mingw32/bin/ld.exe) supports shared libraries... yes checking for g++ option to produce PIC... -DDLL_EXPORT checking if g++ PIC flag -DDLL_EXPORT works... yes checking if g++ static flag -static works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (c:/mingw/mingw32/bin/ld.exe) supports shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking for ANSI C header files... (cached) yes checking curl/curl.h usability... yes checking curl/curl.h presence... yes checking for curl/curl.h... yes checking ostream usability... yes checking ostream presence... yes checking for ostream... yes checking for curl >= 7.10.0... 7.19.6 checking enable gcc warnings... yes checking warning make an error on compilation... no checking whether to enable the maintener code... no checking whether to enable Debug symbols support options... no checking if we need BUILDING_CURLPP... yes checking if we need CURLPP_STATICLIB... yes configure: creating ./config.status config.status: creating curlpp-config config.status: creating curlpp.spec config.status: creating curlpp.pc config.status: creating Makefile config.status: creating examples/Makefile config.status: creating src/Makefile config.status: creating src/curlpp/Makefile config.status: creating src/curlpp/internal/Makefile config.status: creating src/utilspp/Makefile config.status: creating include/Makefile config.status: creating include/curlpp/Makefile config.status: creating include/curlpp/internal/Makefile config.status: creating include/utilspp/Makefile config.status: creating include/utilspp/functor/Makefile config.status: creating include/utilspp/singleton/Makefile config.status: creating doc/Makefile config.status: creating include/curlpp/config.h config.status: include/curlpp/config.h is unchanged config.status: executing depfiles commands 2. make - see a lot of warnings like warning: 'curlpp::internal::SList::SList(const curlpp::internal::SList&)' redeclared without dllimport attribute: previous dllimport ignored in attached file2.txt What is the expected output? What do you see instead? compilation, but instead see linker errors What version of the product are you using? On what operating system? Please provide any additional information below.

What steps will reproduce the problem? 1. ./configure --with-boost=/c/Tools/boost --disable-shared --disable-ewarning -prefix=/mingw Produces the following: checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether ln -s works... yes checking whether make sets $(MAKE)... (cached) yes checking for gcc... gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking for a BSD-compatible install... /bin/install -c checking how to run the C++ preprocessor... g++ -E checking for a sed that does not truncate output... /bin/sed checking for Boost headers version >= 0... /c/Tools/boost/include/boost-1_40 checking for Boost's header version... 1_40 checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ld used by gcc... c:/mingw/mingw32/bin/ld.exe checking if the linker (c:/mingw/mingw32/bin/ld.exe) is GNU ld... yes checking for c:/mingw/mingw32/bin/ld.exe option to reload object files... -r checking for BSD-compatible nm... /mingw/bin/nm checking how to recognise dependent libraries... file_magic file format pei*-i386(.*architecture: i386)? checking for dlltool... dlltool checking for as... as checking for objdump... objdump checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... no checking dlfcn.h presence... no checking for dlfcn.h... no checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for xlf95... no checking for f95... no checking for fort... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 8192 checking command to parse /mingw/bin/nm output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -DDLL_EXPORT checking if gcc PIC flag -DDLL_EXPORT works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (c:/mingw/mingw32/bin/ld.exe) supports shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... no checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... c:/mingw/mingw32/bin/ld.exe checking if the linker (c:/mingw/mingw32/bin/ld.exe) is GNU ld... yes checking whether the g++ linker (c:/mingw/mingw32/bin/ld.exe) supports shared libraries... yes checking for g++ option to produce PIC... -DDLL_EXPORT checking if g++ PIC flag -DDLL_EXPORT works... yes checking if g++ static flag -static works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (c:/mingw/mingw32/bin/ld.exe) supports shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking for ANSI C header files... (cached) yes checking curl/curl.h usability... yes checking curl/curl.h presence... yes checking for curl/curl.h... yes checking ostream usability... yes checking ostream presence... yes checking for ostream... yes checking for curl >= 7.10.0... 7.19.6 checking enable gcc warnings... yes checking warning make an error on compilation... no checking whether to enable the maintener code... no checking whether to enable Debug symbols support options... no checking if we need BUILDING_CURLPP... yes checking if we need CURLPP_STATICLIB... yes configure: creating ./config.status config.status: creating curlpp-config config.status: creating curlpp.spec config.status: creating curlpp.pc config.status: creating Makefile config.status: creating examples/Makefile config.status: creating src/Makefile config.status: creating src/curlpp/Makefile config.status: creating src/curlpp/internal/Makefile config.status: creating src/utilspp/Makefile config.status: creating include/Makefile config.status: creating include/curlpp/Makefile config.status: creating include/curlpp/internal/Makefile config.status: creating include/utilspp/Makefile config.status: creating include/utilspp/functor/Makefile config.status: creating include/utilspp/singleton/Makefile config.status: creating doc/Makefile config.status: creating include/curlpp/config.h config.status: include/curlpp/config.h is unchanged config.status: executing depfiles commands 2. make - see a lot of warnings like warning: 'curlpp::internal::SList::SList(const curlpp::internal::SList&)' redeclared without dllimport attribute: previous dllimport ignored in attached file2.txt What is the expected output? What do you see instead? compilation, but instead see linker errors What version of the product are you using? On what operating system? Please provide any additional information below.

Last 30 days

Older