bug-gettext
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: building GNU gettext on AIX


From: David Edelsohn
Subject: Re: building GNU gettext on AIX
Date: Thu, 16 Nov 2023 18:38:55 -0500

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]