libiconv pulled in by pkg upgrade? lots of errors after that
Tijl Coosemans
tijl at FreeBSD.org
Mon Feb 24 12:31:10 UTC 2014
On Sun, 23 Feb 2014 20:05:36 -0800 (PST) Thomas Mueller wrote:
> from Tijl Coosemans:
>> On Sun, 23 Feb 2014 10:57:12 +0000 (UTC) Thomas Mueller wrote:
>>> 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.
When I said that some care must be taken during compilation, I meant by
port maintainers, not by users, so indeed you don't need WITHOUT_ICONV.
In fact there's nothing special you need to do at all that would require
an entry in UPDATING. If a port depends on libiconv then just let them
like with any other dependency. If a port doesn't build with libiconv
installed then just report that like with any other build failure.
More information about the freebsd-ports
mailing list