Hello David, Build is broken after your last commit:
../lib/.libs/libboinc_fcgi.a(libboinc_fcgi_la-keyword.o): In function `KEYWORD::write_xml(MIOFILE&)': /home/travis/build/BOINC/boinc/lib/keyword.cpp:50: undefined reference to `MIOFILE::FCGI_printf(char const*, ...)' ../lib/.libs/libboinc_fcgi.a(libboinc_fcgi_la-keyword.o): In function `JOB_KEYWORD_IDS::write_xml_num(MIOFILE&)': /home/travis/build/BOINC/boinc/lib/keyword.cpp:129: undefined reference to `MIOFILE::FCGI_printf(char const*, ...)' /home/travis/build/BOINC/boinc/lib/keyword.cpp:132: undefined reference to `MIOFILE::FCGI_printf(char const*, ...)' /home/travis/build/BOINC/boinc/lib/keyword.cpp:135: undefined reference to `MIOFILE::FCGI_printf(char const*, ...)' ../lib/.libs/libboinc_fcgi.a(libboinc_fcgi_la-keyword.o): In function `JOB_KEYWORD_IDS::write_xml_text(MIOFILE&, KEYWORDS&)': /home/travis/build/BOINC/boinc/lib/keyword.cpp:117: undefined reference to `MIOFILE::FCGI_printf(char const*, ...)' ../lib/.libs/libboinc_fcgi.a(libboinc_fcgi_la-keyword.o):/home/travis/build/BOINC/boinc/lib/keyword.cpp:122: more undefined references to `MIOFILE::FCGI_printf(char const*, ...)' follow collect2: error: ld returned 1 exit status make[2]: *** [fcgi] Error 1 make[2]: Leaving directory `/home/travis/build/BOINC/boinc/sched' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/travis/build/BOINC/boinc' make: *** [all] Error 2 Please fix it. Thanks Best regards, Vitalii Koshura 2017-07-30 17:39 GMT+03:00 Vitalii Koshura <lestat.de.lion...@gmail.com>: > Hello all, > > In a perfect world such kind of changes are made in a separate branch. > This helps to avoid broken builds. > Also we have a pull request https://github.com/BOINC/boinc/pull/1821 > which also can notify developer about broken build. > > @David, could you please take a look at this pull request and at least do > not commit unfinished work in master (making all changes in a separate > branch iseven better)? > > Thanks > > Best regards, > Vitalii Koshura > > 2017-07-30 12:52 GMT+03:00 Richard Haselgrove < > r.haselgr...@btopenworld.com>: > >> I pointed out the Travis build error report almost 12 hours ago, on a >> mailing list which I know David reads. >> >> I don't have your expertise in tracking down the cause of the error (and >> I don't think I have access to the Travis error messages), but in a case >> like this, shouldn't the developer temporarily revert the commit, and come >> back to it later with a fresh pair of eyes to make a second attempt? >> >> On Sunday, 30 July 2017, 10:40, Charlie Fenton < >> charl...@ssl.berkeley.edu> wrote: >> >> >> The latest commit for keyword.cpp and keyword.h broke the builds on the >> Mac. >> >> [1] Adding #include <map> after #include "parse.h" fixes the compiler >> errors for keyword.h, but I don't know if this needs to be guarded by >> #ifdef __APPLE__ or if it is OK (and perhaps even necessary) to include it >> for all platforms, so I have not checked it in. >> >> [2] After making that change in keyword.h, I get these compiler errors in >> keyword.cpp: >> > ..../lib/keyword.cpp:47:9: error: cannot pass object of non-POD type >> 'std::string' (aka 'basic_string<char>') through variadic method; call will >> abort at runtime [-Wnon-pod-varargs] >> > name, description, parent, level, category >> > ^ >> > ..../lib/keyword.cpp:47:15: error: cannot pass object of non-POD type >> 'std::string' (aka 'basic_string<char>') through variadic method; call will >> abort at runtime [-Wnon-pod-varargs] >> > name, description, parent, level, category >> > ^ >> >> According to <https://stackoverflow.com/questions/146452/what-are-pod-typ >> es-in-c>: >> > POD stands for Plain Old Data - that is, a class (whether defined with >> the keyword struct or the keyword class) without constructors, destructors >> and virtual members functions. Wikipedia's article on POD goes into a bit >> more detail and defines it as: >> > >> > A Plain Old Data Structure in C++ is an aggregate class that contains >> only PODS as members, has no user-defined destructor, no user-defined copy >> assignment operator, and no nonstatic members of pointer-to-member type. >> >> <https://stackoverflow.com/questions/10440966/c-cannot-pass- >> objects-of-non-pod-type> explains it this way: >> > The problem you have is that variable argument functions do not work on >> non-POD types, including std::string. That is a limiation of the system and >> cannot be modified. What you can, on the other hand, is change your code to >> pass a POD type (in particular a pointer to a nul terminated character >> array): >> >> >> And <https://stackoverflow.com/questions/18319619/c-snprintf-can >> not-pass-objects-of-non-pod-type> explains a similar case this way: >> > snprintf knows nothing about std::string. In this case, it expects >> null-terminated C strings, that is, pointers to char which are the >> beginning of a sequence of characters that ends in a null character. You >> can obtain the underlying null terminated string held by a std::string >> object via its c_str() method: >> >> Cheers, >> --Charlie >> >> _______________________________________________ >> boinc_dev mailing list >> boinc_dev@ssl.berkeley.edu >> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >> To unsubscribe, visit the above URL and >> (near bottom of page) enter your email address. >> >> >> >> _______________________________________________ >> boinc_dev mailing list >> boinc_dev@ssl.berkeley.edu >> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >> To unsubscribe, visit the above URL and >> (near bottom of page) enter your email address. >> > > _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
