libiconv pulled in by pkg upgrade? lots of errors after that

[Thomas Mueller]

from Tijl Coosemans:

> On Sun, 23 Feb 2014 10:57:12 +0000 (UTC) Thomas Mueller wrote:
> > From other posts on emailing lists, I see libiconv from ports supports
> > utf-8, while base (>=10) does not.
        
> No, utf-8 works fine with base iconv.  Base iconv does not recognise the
> special encoding named "wchar_t" which means whatever encoding is used for
> the C/C++ type wchar_t with libiconv.
        
> > Now I want to know what would happen if I rebuild system with
> > WITHOUT_ICONV=yes
> > in /etc/src.conf
> > and use libiconv from ports.
>
> > Would it work, and would I have to rebuild all ports?

> It would work and it's probably easiest to rebuild all ports.  Technically
> you only need to rebuild these packages:

> grep -Rl __bsd_iconv /usr/local | xargs -n1 pkg which | sed 's/.* //' | sort -u

> > It seems including libiconv in base has adverse side effects, the two
> > can clash when both base and ports libiconv are installed.
        
> The two can coexist.  It's just that some care must be taken during
> compilation.

I guess I need to check which ports use which shared libraries, using pkg?

So maybe I don't need WITHOUT_ICONV in /etc/src.conf ?

Maybe base iconv could be enhanced to be identical to the port, by adding wchar_t support?

I like Lev Serebryakov's idea of a notice in UPDATING, and would add that such a notice on possible iconv conflicts could be added tp UPDATING for both the ports tree and system-source tree.

Tom