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.
Attachment:
signature.asc
Description: OpenPGP digital signature