From: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Use Solaris iconv
Date: Thu, 20 Aug 2026 20:00:16 +0200 [thread overview]
Message-ID: <yddzeyghdu7.fsf@CeBiTec.Uni-Bielefeld.DE> (raw)
In-Reply-To: <87o6ewu4yz.fsf@tromey.com> (Tom Tromey's message of "Thu, 20 Aug 2026 10:33:24 -0600")
Hi Tom,
>>>>>> "Rainer" == Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:
>
> Rainer> However, Solaris 11.4 iconv is good enough to use: enabling its use
> Rainer> fixes 300+ failures.
>
> Rainer> Ok for trunk?
>
> I think it's fine, but my question here is whether gdb intends to
> support versions of Solaris where this might not work.
I've thought about this but decided not to care for anything but Solaris
11.4 for a couple of reasons:
* Over in GCC, I've obsoleted all versions up to and including 11.3 in
GCC 13. Support was finally removed in GCC 15. In all that time, I'm
not aware of even a single complaint about this.
* Even though GDB might well work on pre-11.4 versions, I'm certainly
not going to test this. Howver, unless someone else steps forward to
do so, untested support is useless IMO
* Right now, without this patch, users get confusing warnings and tons
of errors, so this is a massive improvement at little cost, so anyone
using 11.4 benefits without further effort, rather than having to use
GNU libiconv, which isn't bundled with Solaris.
* Solaris iconv certainly has it's issues. However, when investigating
GCC PR c++/112652, I learned that it hasn't been touched in many
years, so it's unlikely that there are considerable changes since at
least Solaris 11.0 15 years ago.
* Last but not least, users always have the option to use GNU libiconv
instead.
> Rainer> - Finally, some systems do not have iconv, or are really broken
> Rainer> - (e.g., Solaris, which almost has all of this working, but where
> Rainer> - just enough is broken to make it too hard to use). Here we provide
> Rainer> - a phony iconv which only handles a single character set, and we
>
> Ages ago I wrote this text, and it was true at the time. IIRC, Solaris
> back then used some undocumented, idiosyncratic, system-specific wchar_t
> encoding and there was no way to convert from the regular encodings to
> wchar_t via iconv, or something like that.
>
> I don't know when Solaris changed to using Unicode.
Me neither: I'd guess it was in the Solaris 10 timeframe (21 years ago
now), when POSIX.1-2001 support was introduced. TBH I haven't
researched since that's all ancient history now.
> Anyway I guess the question I have is whether this:
>
> Rainer> - || (defined (_LIBICONV_VERSION) && _LIBICONV_VERSION >= 0x108))
> Rainer> + || (defined (_LIBICONV_VERSION) && _LIBICONV_VERSION >= 0x108) \
> Rainer> + || (defined (__sun__) && defined (__svr4__)))
>
> ... should check some kind of Solaris version.
I guess there's no use in that. While Studio cc predefines
__SunOS_RELEASE, gcc does not, so this would have to be done via a
configure test. Not worth the trouble, I believe.
> If not, maybe adding some note to the commit message on this topic would
> be nice to have.
Will do.
BTW., given the benefit and no impact for other OSes, this might be a
candidate for the GDB 18 release. Thoughts?
Thanks.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
next prev parent reply other threads:[~2026-08-20 18:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-19 12:23 Rainer Orth
2026-08-20 16:33 ` Tom Tromey
2026-08-20 18:00 ` Rainer Orth [this message]
2026-08-20 18:27 ` Simon Marchi
2026-08-21 15:08 ` Tom Tromey
2026-08-22 20:19 ` Rainer Orth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=yddzeyghdu7.fsf@CeBiTec.Uni-Bielefeld.DE \
--to=ro@cebitec.uni-bielefeld.de \
--cc=gdb-patches@sourceware.org \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox