Re: [PATCH] gdbserver/linux: probe for libiconv in configure

[Simon Marchi <simon.marchi@efficios.com>]

On 2/29/24 12:40, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi <simon.marchi@polymtl.ca> writes:
> 
> Simon> I downloaded GNU libiconv, built it for that host, and installed it in
> Simon> an arbitrary directory.  To make gdbserver use it, I had to modify the
> Simon> gdbserver build system to locate libiconv and use it, the result is this
> Simon> patch.
> 
> Simon> I eventually found that crosstool-ng has an config option to make uclibc
> Simon> provide an implementation of iconv, which is of course much easier.  But
> Simon> given that this patch is now written, I think it would be worth merging
> Simon> it.  It could help some people who do not have iconv built in their libc
> Simon> and may not have the luxury of rebuilding their libc like I do.
> 
> gdb also supports in-tree building of libiconv.  To support this case,
> you have to patch the top-level to add dependencies on libiconv to
> gdbserver.  I think it's safe to just copy the gdb code there.

Ok, done.

> Simon> To avoid unnecessarily linking against libiconv on hosts that don't need
> Simon> it, set `MAYBE_LIBICONV` with the contents of `LIBICONV` only if the
> Simon> host is Linux, and use `MAYBE_LIBICONV` in `Makefile.in`.  I considered
> Simon> putting `AM_ICONV` in the case, to avoid unnecessarily doing the
> Simon> configure checks for the hosts that don't need libiconv, but I'm not
> Simon> sure it's safe.
> 
> IIRC the way it's supposed to work is that the LIBICONV substitution
> variable is just set to the empty string in the case that iconv is
> available in libc. 
> 
> So, just calling AM_ICONV should be sufficient on the configure side.

> I don't think adding some more checks to all hosts is a big enough deal
> to bother with the 'case'.

The case is not to avoid the configure check, but to avoid linking
against libiconv on hosts where gdbserver doesn't need libiconv.

Let's say you're on freebsd and that on freebsd libiconv is a separate
library, not built into libc.  gdbserver on freebsd doesn't need
libiconv.  So even if libiconv is found by AM_ICONV, I don't want to
pass those flags ($LIBICONV) to the linker, on freebsd.  That's why I
introduced the MAYBE_LIBICONV variable, which is only set for Linux
hosts

But if you tell me that linking against libiconv even if not necessary
is not a big deal, I can simplify it.

> Probably the source has to be updated to check HAVE_ICONV and do
> something sensible if it isn't found.  One option would be to just
> replace problem characters... the underlying problem being solved here
> is that a thread name is a limited number of bytes, so a UTF-8 thread
> name might be truncated mid-character.

The way I made it is that for hosts where we use libiconv (just Linux
for the time being), libiconv is a hard dependency (configure errors out
if libiconv is not found).  So, no need to change the code itself.

Simon