Re: converters/libiconv-1.16

[Greg Troxel <gdt%lexort.com@localhost>]

Kamil Rytarowski <n54%gmx.com@localhost> writes:

> On 11.10.2019 14:56, Greg Troxel wrote:
>> Kamil Rytarowski <n54%gmx.com@localhost> writes:
>> 
>>> ./build.sh picks /usr/pkg/include (or $PREFIX) paths by default as they
>>> are detected by autoconf. I don't remember ofhand the reason for it, it
>>> could be pkg-config that is used by ./build.sh tools.
>> 
>> So perhaps build.sh should not use pkgsrc paths.
>> 
>> 
>>> It would be ideal to blacklist packages from pkgsrc that interfere with
>>> the process of bootstrapping tools.
>> 
>> Do you mean:
>> 
>>   change build.sh not to look at them
>> 
>> or
>> 
>>   ban them from pgksrc?
>> 
>> The second seems unreasonable.
>
> As long as the former is not addressed, I have personally the latter
> rule in effect. If libiconv will be picked for more software it will be
> harder to avoid it and this is not wanted for me locally.
>
> As a general rule please try to reuse native iconv() whenever possible.
> It's comparable to picking native sed(1) instead of forcing gsed for no
> good reason.

That is the general approach in pkgsrc already.

>>> Before that, libiconv causes harm as /usr/pkg/include is in the search
>>> path, and prior /usr/include for headers with overlapping names.
>> 
>> OK, but then the library should be linked, and that should be ok.
>
> This can only work when libiconv was searched deliberately and not
> picked by an accident. GDB from src tools searches for a library for
> highlighting code syntax.

What I meant is that if a build system finds /usr/pkg/include/iconv.h it
should be linking the library as well, and if not it should be fixed.

> Another approach would be to namespace the libiconv header (such as
> installing it into $PREFIX/include/libiconv/), so it will be harder to
> be picked by an accident.

We don't in general do this for pkgsrc things that can shadow base.

It sounds like you should take pkgsrc out of the PATH when you are using
build.sh.