Re: building GNU gettext on AIX

[David Edelsohn <dje.gcc@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3388 bytes --]

On Thu, Nov 16, 2023 at 5:47 PM Bruno Haible <bruno@clisp.org> wrote:

> Hi David,
>
> > the default, distributed libintl library will not allow GCC to be built
> > with NLS enabled.
>
> The problem is this configure test from gettext.m4
>
>   checking for GNU gettext in libintl... no
>
> It should say
>
>   checking for GNU gettext in libintl... yes
>
> I reproduce it with simple hello-world package, outside GCC.
>
> It tests whether a program that uses gettext() can be linked with
>   -lintl -liconv
> But now, on AIX, it needs to test whether such a program can be linked with
>   -lintl -liconv -lpthread
>
> > Were you suggesting that --enable-threads=isoc would work now or that it
> > would require further changes for a future release?
>
> It requires a change, effectively to do as if HAVE_PTHREAD_API is undefined
> if --enable-threads=isoc was provided.
>
> I can prepare a new gettext release that has both issues fixed:
>   - gettext.m4 that fixes the configure test and sets the variable LIBINTL
>     to "-Lsome/libdir -lintl -liconv -lpthread",
>   - mbrtowc.o and setlocale*.o that use mtx_* locks instead of pthread_*
>     mutexes when requested.
>
> But you then need to make up your mind w.r.t. what I wrote in the earlier
> mail.
>
>   * GCC can pass --enable-threads=isoc, to avoid the libpthread dependency
>     on AIX ≥ 7.2.
>

I have reached out to the AIX Open Source Tools team for their
perspective.  Normally GCC and other
FOSS packages have not based their support for OS versions on official
vendor support lifecycles,
within reason.  In fact, many users have appreciated longer duration
support.


>
>   * Or GCC can (continue to?) use the variable LIBINTL. This will work on
>     AIX 7.1 as well but the programs will then be linked against
> libpthread.
>     One additional library.
>     $ ldd gcc
>     /opt/freeware/bin/gcc needs:
>          /usr/lib/libc.a(shr.o)
>          /opt/freeware/lib/libiconv.a(libiconv.so.2)
>          /usr/lib/libc.a(_shr.o)
>          /unix
>          /usr/lib/libcrypt.a(shr.o)
>          /opt/freeware/lib/libgcc_s.a(shr.o)
>     libpthread.a will be added to this list.
>

My builds of GCC only rely on AIX libc.  All other libraries are statically
linked.


>
>     ibm-clang links against libpthread.a as well:
>     $ ldd /opt/IBM/openxlC/17.1.1/bin/.ibm-clang.orig
>     /opt/IBM/openxlC/17.1.1/bin/.ibm-clang.orig needs:
>          /usr/lib/libpthreads.a(shr_xpg5_64.o)
>          /usr/opt/zlibNX/lib/libz.a(libz.so.1)
>          /usr/lib/libcurses.a(shr42_64.o)
>          /usr/lib/libiconv.a(shr4_64.o)
>          /usr/lib/libc++.a(shr_64.o)
>          /usr/lib/libc++abi.a(libc++abi.so.1)
>          /usr/lib/libc.a(shr_64.o)
>          /usr/lib/libpthreads.a(_shr_xpg5_64.o)
>          /usr/lib/libc++.a(libc++.so.1)
>          /usr/lib/libunwind.a(libunwind.so.1)
>          /usr/lib/libc.a(_shr_64.o)
>          /unix
>          /usr/lib/libcrypt.a(shr_64.o)
>

I have asked the IBM Clang team why ibm-clang depends on libpthreads.

One option is to add -lpthreads to the link line, even if the tools are not
built
thread-safe.  Only the intl support would invoke the extraneous overhead.
The downside is that other pthreads dependencies could sneak in.

Thanks, David


>
> Bruno
>
>
>
>