Closed phloxic closed 8 years ago
Minoru
commented
8 years ago Hmm, json-c 0.12 deprecated some stuff, but Mac OS X seems to be the only one who caught up with this release (even Gentoo still masks it). Guess I'll have to add a workaround.
phloxic
commented
8 years ago I'm building json-c myself, probably could downgrade it. But, yes, a workaround would nice to have[tm]. Thanks.
Minoru
commented
8 years ago I tried building HEAD with json-c 0.12, and I can confirm that compiler emits deprecation warnings; I'm working on fixing those.
But the errors I couldn't reproduce; my installation seem to find is_error just fine (and I can confirm that json-c 0.12 still has such a macro, see bits.h:26).
Can you try with the current HEAD and json-c-0.12?
Minoru
commented
8 years ago 0adf49fb86abf334f33dd925541771e741caeac4 should've fixed deprecation warnings.
phloxic
commented
8 years ago @Minoru - yes. With json-c-0.12 I get:
clang++ -std=c++11 -ggdb -Iinclude -Istfl -Ifilter -I. -Irss -Wall -Wextra -Wunreachable-code -DLOCALEDIR=\"/usr/local/share/locale\" -I/sw/include -I/sw/include -I/sw/include/libxml2 -I/sw/include -I/usr/local/include -I/usr/local/include/json-c -I/usr/include/ncurses -o newsbeuter newsbeuter.o src/cache.o src/htmlrenderer.o src/urlreader.o src/logger.o src/view.o src/controller.o src/reloadthread.o src/tagsouppullparser.o src/downloadthread.o src/rss.o src/rss_parser.o src/formaction.o src/feedlist_formaction.o src/itemlist_formaction.o src/itemview_formaction.o src/help_formaction.o src/filebrowser_formaction.o src/urlview_formaction.o src/select_formaction.o src/history.o src/filtercontainer.o src/listformatter.o src/regexmanager.o src/dialogs_formaction.o src/ttrss_api.o src/ttrss_urlreader.o src/newsblur_api.o src/newsblur_urlreader.o src/markreadthread.o src/oldreader_urlreader.o src/oldreader_api.o src/feedhq_api.o src/feedhq_urlreader.o -lbeuter -lfilter -lpthread -lrsspp -liconv -lintl -L. -fprofile-arcs -ftest-coverage -L/sw/lib -lsqlite3 -L/sw/lib -lcurl -L/sw/lib -lxml2 -L/usr/local/lib -lstfl -L/usr/local/lib -ljson-c -lncurses
Undefined symbols for architecture x86_64:
"_mvwaddnwstr", referenced from:
_stfl_print_richtext in libstfl.a(base.o)
_wt_input_draw in libstfl.a(wt_input.o)
_wt_label_draw in libstfl.a(wt_label.o)
_wt_list_draw in libstfl.a(wt_list.o)
_wt_textview_draw in libstfl.a(wt_textview.o)
"_mvwaddwstr", referenced from:
_wt_input_draw in libstfl.a(wt_input.o)
"_wget_wch", referenced from:
_stfl_form_run in libstfl.a(base.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Makefile:76: recipe for target 'newsbeuter' failed
make: *** [newsbeuter] Error 1Unfortunately I am unable to build a new stfl, I was only able to because I changed a lot of params in the Makefile, but that doesn't work anymore either.
FYI, with json-c git HEAD I get:
clang++ -std=c++11 -ggdb -Iinclude -Istfl -Ifilter -I. -Irss -Wall -Wextra -Wunreachable-code -DLOCALEDIR=\"/usr/local/share/locale\" -I/sw/include -I/sw/include -I/sw/include/libxml2 -I/sw/include -I/usr/local/include -I/usr/local/include/json-c -I/usr/include/ncurses -o src/ttrss_api.o -c src/ttrss_api.cpp
src/ttrss_api.cpp:115:6: error: use of undeclared identifier 'is_error'; did you mean 'mc_error'?
if (is_error(reply)) {
^~~~~~~~
mc_error
/usr/local/include/json-c/debug.h:28:13: note: 'mc_error' declared here
extern void mc_error(const char *msg, ...);
^
src/ttrss_api.cpp:115:15: error: cannot initialize a parameter of type 'const char *' with an lvalue of type
'json_object *'
if (is_error(reply)) {
^~~~~
/usr/local/include/json-c/debug.h:28:34: note: passing argument to parameter 'msg' here
extern void mc_error(const char *msg, ...);
^
src/ttrss_api.cpp:122:6: error: use of undeclared identifier 'is_error'; did you mean 'mc_error'?
if (is_error(status)) {
^~~~~~~~
mc_error
/usr/local/include/json-c/debug.h:28:13: note: 'mc_error' declared here
extern void mc_error(const char *msg, ...);
^
src/ttrss_api.cpp:122:15: error: cannot initialize a parameter of type 'const char *' with an lvalue of type
'json_object *'
if (is_error(status)) {
^~~~~~
/usr/local/include/json-c/debug.h:28:34: note: passing argument to parameter 'msg' here
extern void mc_error(const char *msg, ...);
^
src/ttrss_api.cpp:129:6: error: use of undeclared identifier 'is_error'; did you mean 'mc_error'?
if (is_error(content)) {
^~~~~~~~
mc_error
/usr/local/include/json-c/debug.h:28:13: note: 'mc_error' declared here
extern void mc_error(const char *msg, ...);
^
src/ttrss_api.cpp:129:15: error: cannot initialize a parameter of type 'const char *' with an lvalue of type
'json_object *'
if (is_error(content)) {
^~~~~~~
/usr/local/include/json-c/debug.h:28:34: note: passing argument to parameter 'msg' here
extern void mc_error(const char *msg, ...);
^
6 errors generated.
Makefile:101: recipe for target 'src/ttrss_api.o' failed
make: *** [src/ttrss_api.o] Error 1I probably have to cross my fingers that my old installation keeps working as long as possible.
Minoru
commented
8 years ago Undefined symbols for architecture x86_64: "_mvwaddnwstr" "_mvwaddwstr" "_wget_wch"
Are you sure your STFL built properly? Looks like you didn't link it to ncursesw or something.
I didn't realise you were building against json-c's HEAD, I just assumed you were on json-c-0.12. Sorry about that. Current json-c deprecated is_error(), thus the errors you get. I fixed this in the latest commit.
Minoru
commented
8 years ago Are you sure your STFL built properly? Looks like you didn't link it to ncursesw or something.
I should clarify that. After compiling with clang on Linux and diffing respective command lines, I found that your side links to ncurses instead of ncursesw (which is required for wide character support). Your side also doesn't link to tinflow, but I'm not sure if this one is necessary for OS X build. Hope that helps.
phloxic
commented
8 years ago Currently I don't have the time to convince stifl to build only libstfl.a with clang-700.1.81 - I never found a way to build *.dylib. The build I have works fine with an old version of newsbeuter and json-c v0.12 (which creates libjson-c.2.dylib).
I'll keep you updated when I find time. The showstopper is basically stfl.
Minoru
commented
8 years ago I found that your side links to ncurses instead of ncursesw
Okay, I've just finished reading config.sh and found that on OS X, this is to be expected. So now I don't know whom to blame. Damn! :)
To test your STFL, try building examples from its site. You know, just to make sure it's the library who's at fault, not newsbeuter or something else.
phloxic
commented
8 years ago well, I happen to have the very latest ncurses(w)6 installed (because they provide e.g. the tmux TERM entry) - but hacking config.sh to use that also fails with the same error. So I assume I have to find a way to re-build stfl.
phloxic
commented
8 years ago ok, managed to build stfl:
$ otool -L /usr/local/lib/libstfl.dylib
/usr/local/lib/libstfl.dylib:
/usr/local/lib/libstfl.0.24.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libncursesw.6.dylib (compatibility version 6.0.0, current version 6.0.0)
/sw/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)And, more importantly, newsbeuter, with config.sh adapted to use my ncursesw:
$ otool -L `which newsbeuter`
/usr/local/bin/newsbeuter:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
/sw/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0)
/sw/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.3.0)
/sw/lib/libsqlite3.0.dylib (compatibility version 9.0.0, current version 9.6.0)
/sw/lib/libcurl.4.dylib (compatibility version 9.0.0, current version 9.0.0)
/sw/lib/libxml2.2.dylib (compatibility version 12.0.0, current version 12.1.0)
/usr/local/lib/libstfl.0.24.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libjson-c.3.dylib (compatibility version 4.0.0, current version 4.0.0)
/usr/local/lib/libncurses.6.dylib (compatibility version 6.0.0, current version 6.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)To be precise, I was able to build d483d4e756c8. FYI git HEAD fails with:
clang++ -I/usr/local/include -I/sw/include -I/opt/X11/include -std=c++11 -ggdb -Iinclude -Istfl -Ifilter -I. -Irss -Wall -Wextra -Wunreachable-code -DLOCALEDIR=\"/usr/local/share/locale\" -I/sw/include -I/sw/include -I/sw/include/libxml2 -I/sw/include -I/usr/local/include -I/usr/local/include/json-c -D_DARWIN_C_SOURCE -I/usr/local/include -I/usr/local/include -I/sw/include -I/opt/X11/include -std=c++11 -ggdb -Iinclude -Istfl -Ifilter -I. -Irss -Wall -Wextra -Wunreachable-code -DLOCALEDIR=\"/usr/local/share/locale\" -o src/configcontainer.o -c src/configcontainer.cpp
In file included from src/configcontainer.cpp:2:
In file included from include/configcontainer.h:4:
In file included from include/configparser.h:4:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:265:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__bit_reference:15:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:627:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/utility:342:16: error:
object of type 'newsbeuter::configdata' cannot be assigned because its copy assignment operator is implicitly
deleted
second = _VSTD::forward<second_type>(__p.second);
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/map:614:15: note:
in instantiation of member function 'std::__1::pair<std::__1::basic_string<char>,
newsbeuter::configdata>::operator=' requested here
{__nc = std::move(__v.__nc); return *this;}
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__tree:1215:35: note:
in instantiation of member function 'std::__1::__value_type<std::__1::basic_string<char>,
newsbeuter::configdata>::operator=' requested here
__cache->__value_ = *__first;
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/map:950:21: note:
in instantiation of function template specialization
'std::__1::__tree<std::__1::__value_type<std::__1::basic_string<char>, newsbeuter::configdata>,
std::__1::__map_value_compare<std::__1::basic_string<char>, std::__1::__value_type<std::__1::basic_string<char>,
newsbeuter::configdata>, std::__1::less<std::__1::basic_string<char> >, true>,
std::__1::allocator<std::__1::__value_type<std::__1::basic_string<char>, newsbeuter::configdata> >
>::__assign_unique<const std::__1::pair<const std::__1::basic_string<char>, newsbeuter::configdata> *>' requested
here
__tree_.__assign_unique(__il.begin(), __il.end());
^
src/configcontainer.cpp:20:14: note: in instantiation of member function 'std::__1::map<std::__1::basic_string<char>,
newsbeuter::configdata, std::__1::less<std::__1::basic_string<char> >, std::__1::allocator<std::__1::pair<const
std::__1::basic_string<char>, newsbeuter::configdata> > >::operator=' requested here
config_data = {
^
include/configcontainer.h:24:40: note: copy assignment operator of 'configdata' is implicitly deleted because field
'enum_values' has no copy assignment operator
const std::unordered_set<std::string> enum_values;
^
1 error generated.
Makefile:101: recipe for target 'src/configcontainer.o' failed
make: *** [src/configcontainer.o] Error 1Hm. I wonder why it looks for copy assignment when it should've just moved the value… Was it a clean build (i.e., did you run make clean beforehand)? What version of Clang are you using?
But anyway, that was a bad style. Does bugfix/os-x-build compile?
Minoru
commented
8 years ago Never mind my previous response. I've just finished setting up Travis build on OS X and it reported the same error. It also reported that bugfix/os-x-build does work, so I'll merge it right away.
I believe that's it for the scope of this issue. Thank you for reporting!
phloxic
commented
8 years ago Just to confirm that building master HEAD now works. Thanks. FYI:
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin14.5.0
Thread model: posix
Both git HEAD and r2.9 fail to build with:
thx