Re: converters/libiconv-1.16

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

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

>>> 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.
>
> Right, it should be fixed. My fix proposal is to namespace the directory
> with iconv.h from libiconv.

I said the build system should be fixed, not that we should add a
workaround to pkgsrsrc to remove the thing that is triggering a latent
build system bug.

>>> 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.
>
> This is done at least for ncurses this way.

ncurses is messier as curses and ncurses are not the same thing and as I
understand it we have something in base called curses which is actually
ncurses.  (There's a general pattern here which is that all of this is
hard :-)

> Other packages typically don't install headers with the same name in
> libc so there is not a general rule here.

I am really not sure; we have many packages in pkgsrc that are also in
base.   But I agree it's not very common.

>> It sounds like you should take pkgsrc out of the PATH when you are using
>> build.sh.
>
> This is not an option. ./build.sh tools must work as is, especially on
> NetBSD.

There is the approach of fixing build.sh so that t wworks in all
environments in which it might plausibly be invoked.  You seem to think
that we must change the environment, if I'm following you correctly.

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.

For what it's worth, I have libiconv 1.14nb3 installed on my
netbsd-8/amd64 system, and have just recently done builds for 7, 8 and 9
for multiple architectures and everything was fine.  I do in fact have
/usr/pkg/include/iconv.h and /usr/pkg/lib/libiconv.* on this system.  (I
haven't gotten to building current yet; that's something I was going to
do anyway.)

Looking at my netbsd-9 texinfo tool, I see it linked to base libc, and
not to anything in pkgsrc.  Looking at the build log, I don't see any
hint of linking with pkgsrc libiconv.

Are you using for bootstrap the base system gcc, base clang, some other
gcc or clang, and is the other compiler configured to look in
/usr/pkg/include even if you don't pass -I/usr/pkg/include?  Can you
post the line from your build that causes trouble?