Re: converters/libiconv-1.16

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

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

> On 11.10.2019 18:47, Greg Troxel wrote:
>> Martin Husemann <martin%duskware.de@localhost> writes:
>> 
>>> On Fri, Oct 11, 2019 at 11:26:20AM -0400, Greg Troxel wrote:
>>>> Can you explain how /usr/pkg/include/iconv.h is found?  Regardless of
>>>> what's in PATH, I don't see how that would be included.  And, there can
>>>> be arbitrary stuff in /usr/pkg/include, so for robustness build.sh has
>>>> to by default not look there.
>>>
>>> No, it can not explicitly avoid that. This is about the tool build phase,
>>> which does some autoconfigury - it  absolutely hast to work out of the
>>> box in any sane posixish environment w/o modifications of the environment.
>>>
>>> If gdb autoconfigure is broken and picks up mixed things, it should
>>> be fixed.
>> 
>> Given that 1) /usr/pkg is not in the default compiler search paths and
>> 2) NetBSD does not have pkg-config by default, I do not understand why
>> anything in build.sh tools ever looks in /usr/pkg.
>> 
>
> My guess is that programs like pkg-config are picked and pkgsrc is in
> the default PATH by default.
>
> /etc/skel/.profile:PATH=$HOME/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R7/bin:/usr/pkg/bin
> /etc/skel/.profile:PATH=${PATH}:/usr/pkg/sbin:/usr/games:/usr/local/bin:/usr/local/sbin

Probably then the build.sh autoconf/etc. sub-builds for tools should be
patched to not run pkg-config.  If pkg-config is the problem, that
explains the unwanted leaking of /usr/pkg into the build.sh environment.