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