On 11.10.2019 17:26, Greg Troxel wrote: > 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? $ ldd /public/netbsd-root/tooldir.NetBSD-9.99.15-amd64/bin/x86_64--netbsd-gdb /public/netbsd-root/tooldir.NetBSD-9.99.15-amd64/bin/x86_64--netbsd-gdb: -lcurses.8 => /usr/lib/libcurses.so.8 -lterminfo.1 => /usr/lib/libterminfo.so.1 -lc.12 => /usr/lib/libc.so.12 -lutil.7 => /usr/lib/libutil.so.7 -lexpat.1 => /usr/pkg/lib/libexpat.so.1 -llzma.2 => /usr/lib/liblzma.so.2 -lpthread.1 => /lib/libpthread.so.1 -lsource-highlight.4 => /usr/pkg/lib/libsource-highlight.so.4 -lboost_regex.1.71.0 => /usr/pkg/lib/libboost_regex.so.1.71.0 -licudata.64 => /usr/pkg/lib/libicudata.so.64 -licui18n.64 => /usr/pkg/lib/libicui18n.so.64 -licuuc.64 => /usr/pkg/lib/libicuuc.so.64 -lm.0 => /usr/lib/libm.so.0 -lstdc++.9 => /usr/lib/libstdc++.so.9 -lgcc_s.1 => /usr/lib/libgcc_s.so.1 "./build.sh" tools" detects few packages and this means that /usr/pkg/include is added to -I and iconv.h from libiconv is picked by an accident. It later breaks as the there are missing symbols during linking. Removing or similar libiconv from autoconf won't work as it will still be in the compiler search path. I would need to blacklist icu, source_highlight, etc - it might not be a bad idea, but it will be catch the mole game. On 11.10.2019 17:43, Martin Husemann wrote:> If gdb autoconfigure is broken and picks up mixed things, it should > be fixed. This means that GDB should be patched to pick include dirs in a certain order, probably by patching CPPFLAGS/CFLAGS/CXXFLAGS usage. In my opinion it's overkill to keep it around as a local diff (even if we will upstream it). On 11.10.2019 17:26, Greg Troxel wrote:> 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. > It's here relative what is a bug. I am more sympathizing here with a statement that libiconv using POSIX header name iconv.h is a bug here (it should be libiconv.h). Namespacing it in pkgsrc should workaround it an solve the conflicts. On 11.10.2019 17:26, Greg Troxel wrote:> 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 :-) ncurses is an external curses library. It is typically installed with a curses.h -> ncurses/ncurses.h link. In the NetBSD case it would cause a lot of damage so we keep using namespaced headers for ncurses. I strongly propose to either: - stop using libiconv for any NetBSD packages (even marking it as BROKEN as it raises my frustration for breaking the tools build of ./build.sh) or - namespace the header and install it in a custom subdir so it won't be picked by an accident. I'm actually sympathizing with doing these two proposals concurrently. There is no problem for other headers such as stdio.h or similar as nothing else popular installs conflicting filename header.
Description: OpenPGP digital signature