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. >> 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. >> And in general, is there any reason to want libiconv on NetBSD? Why not >> to use the libc version one? If there is a missing feature, better to >> add it in libc, if it is non trivial and libiconv is a stop-gap for >> something in pkgsrc (I suffer because R picks it.. and stopped >> installing it recently), it would be good to first fix the the >> ./build.sh tools scripts. > > Hard to say why. Often the base versions of things are simple and > older, in the BSD tradition, and the pkgsrc version might have some new > features. Some other package might need that, or some program being > built outside of pkgsrc. I don't think you can conclude that anybody > that wants it is confused. > > So agreed that making sure build.sh doesn't have trouble when iconv is > in pkgsrc sounds good. > 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.
Attachment:
signature.asc
Description: OpenPGP digital signature