On 11.10.2019 15:33, Greg Troxel wrote: > 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. > Right, it should be fixed. My fix proposal is to namespace the directory with iconv.h from libiconv. >> 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. Other packages typically don't install headers with the same name in libc so there is not a general rule here. > 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.
Attachment:
signature.asc
Description: OpenPGP digital signature