Re: converters/libiconv-1.16

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

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

> $ 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.

What is the root cause of gdb's autoconf starting to look in /usr/pkg?

Why is boost linked?  Surely one can run build.sh without having to have
particular packages installed?  I thought the point was that build.sh
would work on a bare NetBSD system.  (It seems unwise for gdb to depend
on boost, since boost seems to have frequent API changes -- every time
boost is updated in pkgsrc a bunch of things need to be fixed/updated.)

Similarly, why is icu linked?

And, you are saying that the problem is that the some cc/c++ invocation
in the gdb build read /usr/pkg/include/iconv.h, but did not add
-L/usr/pkg/lib -liconv to the link, and thus breaks at runtime?  I
realize you are not happy about things, but I am not clear on exactly
what is going on.

> 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.

I would like to see a bug upstream and their reaction first.  Overlaying
posix with different implementations does not strike me as necessarily
broken.  pkgsrc tries to stay compatible with upstreams, as each
deviation, particularly if OS specific needs more work.

>  - 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)

Are you doing something different from everybody else?  You are the only
one reporting this problem, so far.


Certainly, if a pkgsrc package that needs iconv works with base, the
package should be such that base is used.  I wonder where this is coming
from on your system, and whether that case can be addressed without
difficulty.   Or, the package could be fixed upstream to only use POSIX
features, and then we can adjust the package.

>  - 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.

Making changes like you suggest is pkgsrc is at best controversial and
would require discussion, so please don't just do it.