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.
