Poppler compile/link issues on Leopard with clang

[Ryan Schmidt]

On Mar 28, 2020, at 06:04, Riccardo Mottola wrote:

> 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.

There's not enough information here to diagnose anything. You didn't show the complete compile line that resulted in that error so I don't know what flags were being supplied to the compiler.

Please file a ticket with the full main.log attached.


> 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"

The official answer to a problem cannot be to tell the user to "switch to gcc". If a port does not compile out of the box, that is a bug and deserves a ticket. If a port requires a particular compiler, the portfile should be modified to indicate that.