Poppler compile/link issues on Leopard with clang
Riccardo Mottola
riccardo.mottola at libero.it
Sat Mar 28 11:04:49 UTC 2020
Hi,
while updating stuff, a new poppler wants to be installed and, as
always, that piece of software is a PITA!!! Every time a new surprise :-P
This is on 10.5 i386
Anyway, first build attempt, link fails with dozens hundreds of missing
symbols. Build with clang 7.0
s/libnssutil3.dylib /opt/local/lib/nss/libnss3.dylib
/opt/local/lib/nspr/libplds4.dylib /opt/local/lib/nspr/libplc4.dylib
/opt/local/lib/nspr/libnspr4.dylib -lm
Undefined symbols for architecture i386:
"std::__codecvt_utf16_base<wchar_t>::do_unshift(__mbstate_t&, char*,
char*, char*&) const", referenced from:
vtable for std::codecvt_utf16<wchar_t, 1114111ul,
(std::codecvt_mode)0> in PageLabelInfo.cc.o
"std::__codecvt_utf16_base<wchar_t>::do_encoding() const", referenced
from:
vtable for std::codecvt_utf16<wchar_t, 1114111ul,
(std::codecvt_mode)0> in PageLabelInfo.cc.o
"std::__codecvt_utf16_base<wchar_t>::do_max_length() const",
referenced from:
vtable for std::codecvt_utf16<wchar_t, 1114111ul,
(std::codecvt_mode)0> in PageLabelInfo.cc.o
"std::__codecvt_utf16_base<wchar_t>::do_always_noconv() const",
referenced from:
vtable for std::codecvt_utf16<wchar_t, 1114111ul,
(std::codecvt_mode)0> in PageLabelInfo.cc.o
"std::__codecvt_utf16_base<wchar_t>::do_in(__mbstate_t&, char const*,
char const*, char const*&, wchar_t*, wchar_t*, wchar_t*&) const",
referenced from:
vtable for std::codecvt_utf16<wchar_t, 1114111ul,
(std::codecvt_mode)0> in PageLabelInfo.cc.o
"std::__codecvt_utf16_base<wchar_t>::do_out(__mbstate_t&, wchar_t
const*, wchar_t const*, wchar_t const*&, char*, char*, char*&) const",
referenced from:
vtable for std::codecvt_utf16<wchar_t, 1114111ul,
(std::codecvt_mode)0> in PageLabelInfo.cc.o
"std::__codecvt_utf16_base<wchar_t>::do_length(__mbstate_t&, char
const*, char const*, unsigned long) const", referenced from:
and goes on forever.
clang 5.0 instead:
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.86.1/goo/GooString.h:68:60:
error: no member named 'move' in namespace 'std'
explicit GooString(std::string&& str) : std::string(std::move(str)) {}
~~~~~^
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.86.1/goo/gfile.cc:61:22:
error: expected namespace name
using namespace std::string_literals;
~~~~~^
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.86.1/goo/gfile.cc:246:41:
error: no matching literal operator for call to 'operator""s' with
arguments of types 'const char *' and 'unsigned long', and no matching
literal operator template
const std::string modeStr = mode + "e"s;
^
3 errors generated.
make[2]: *** [CMakeFiles/poppler.dir/g
now I compile with mighty gcc7.. and it did succeed!
But it is usally preferred for ports to compile with clang on
i386/x86_64 right? So I did not open a ticket just do say "switch to gcc"
Riccardo
More information about the macports-users
mailing list