[PATCH] m4: fix --disable-rpath for AIX

[PATCH] m4: fix --disable-rpath for AIX

[CHIGOT, CLEMENT]

Currently, --disable-rpath will add directly $found_so to the compilation
line. However, on AIX, this will result on the path being hardcoded in
the built binaries.
The only way to avoid hardcoded paths without using linker flags (like
-Wl,-bnoipath) is to add -l$name.
---
 m4/lib-link.m4 | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/m4/lib-link.m4 b/m4/lib-link.m4
index 0ff10731f..01bcfd5ee 100644
--- a/m4/lib-link.m4
+++ b/m4/lib-link.m4
@@ -377,7 +377,12 @@ AC_DEFUN([AC_LIB_LINKFLAGS_BODY],
                  || test "X$found_dir" = "X/usr/$acl_libdirstem" \
                  || test "X$found_dir" = "X/usr/$acl_libdirstem2"; then
                 dnl No hardcoding is needed.
-                LIB[]NAME="${LIB[]NAME}${LIB[]NAME:+ }$found_so"
+                case $host_os in
+                  dnl Using directly $found_so on AIX will result into
+                  dnl hardcoded libraries' path inside binaries.
+                  aix*) LIB[]NAME="${LIB[]NAME}${LIB[]NAME:+ }-L$found_dir -l$name" ;;
+                  *) LIB[]NAME="${LIB[]NAME}${LIB[]NAME:+ }$found_so" ;;
+                esac
               else
                 dnl Use an explicit option to hardcode DIR into the resulting
                 dnl binary.
-- 
2.17.1

Re: [PATCH] m4: fix --disable-rpath for AIX

[Bruno Haible]

Hi Clement,

> Currently, --disable-rpath will add directly $found_so to the compilation
> line. However, on AIX, this will result on the path being hardcoded in
> the built binaries.
> The only way to avoid hardcoded paths without using linker flags (like
> -Wl,-bnoipath) is to add -l$name.

Can you tell on which package and on which AIX version this patch has an
effect?

I tried it with GNU gettext 0.20.1 on AIX 7.1, with gcc and with
--disable-rpath, and found that the generated executables have the same
directories hardcoded as without your patch.

$ gmake ngettext
/bin/sh ../libtool  --tag=CC   --mode=link gcc -DINSTALLDIR=\"/home/haible/prefix32-norpath/bin\" -g -O2  -L/home/haible/prefix32-norpath/lib -o ngettext ngettext-ngettext.o ../gnulib-lib/libgrt.a ../intl/libintl.la -liconv -pthread -liconv  
libtool: link: gcc -DINSTALLDIR=\"/home/haible/prefix32-norpath/bin\" -g -O2 -o .libs/ngettext ngettext-ngettext.o -pthread  -L/home/haible/prefix32-norpath/lib ../gnulib-lib/libgrt.a -L../intl/.libs -lintl -L/opt/freeware/lib -liconv -pthread -Wl,-blibpath:/home/haible/prefix32-norpath/lib:/opt/freeware/lib:/home/haible/prefix32-norpath/lib:/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.8.1:/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.8.1/../../..:/usr/lib:/lib

You can see that the Makefile does not pass abolute library names to 'libtool',
and nevertheless 'libtool' sets the libpath property as shown.

I fear that making --disable-rpath work on AIX is a much harder endeavor...

Bruno

Re: [PATCH] m4: fix --disable-rpath for AIX

[CHIGOT, CLEMENT]

Hi Bruno,

>> Currently, --disable-rpath will add directly $found_so to the compilation
>> line. However, on AIX, this will result on the path being hardcoded in
>> the built binaries.
>> The only way to avoid hardcoded paths without using linker flags (like
>> -Wl,-bnoipath) is to add -l$name.

> Can you tell on which package and on which AIX version this patch has an
effect?

I'm using it in most of the GNU packages (gettext, libiconv, libunistring, ...)
on AIX 6.1. But it should be the same of other AIX versions.

> I tried it with GNU gettext 0.20.1 on AIX 7.1, with gcc and with
> --disable-rpath, and found that the generated executables have the same
> directories hardcoded as without your patch.

> $ gmake ngettext
> /bin/sh ../libtool  --tag=CC   --mode=link gcc -DINSTALLDIR=\"/home/haible/prefix32-norpath/bin\" -g -O2  -L/home/haible/prefix32-norpath/lib -o ngettext ngettext-ngettext.o ../gnulib-lib/libgrt.a ../intl/libintl.la -liconv -pthread -liconv 
> libtool: link: gcc -DINSTALLDIR=\"/home/haible/prefix32-norpath/bin\" -g -O2 -o .libs/ngettext ngettext-ngettext.o -pthread  -L/home/haible/prefix32-norpath/lib ../gnulib-lib/libgrt.a -L../intl/.libs -lintl -L/opt/freeware/lib -liconv -pthread -Wl,-blibpath:/home/haible/prefix32-norpath/lib:/opt/freeware/lib:/home/haible/prefix32-norpath/lib:/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.8.1:/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.8.1/../../..:/usr/lib:/lib

>You can see that the Makefile does not pass abolute library names to 'libtool',
>and nevertheless 'libtool' sets the libpath property as shown.

Actually, I've coupled it with another patch making shared object extension 
being ".a", as it's supposed to be on AIX when -brtl flag isn't present.
By default, so in your case, shared extension is ".so". Therefore, in the
configure, found_so will be null if your system doesn't have any libiconv.so
under /opt/freeware/lib (which it should be).
Could you tell me if you're ending up having "-L/opt/freeware/lib -liconv"
because both "found_a" and "found_so" is null or because of something else ?

Anyway, I think even if this patch doesn't apply to every cases. The current
default behavior of configure is that if a found_so is found (either .a or .so)
and --disable-rpath is provided, it will link with
"/opt/freeware/lib/libname.a" and thus the directory will be hardcoded.
That's doing exactly what we're trying to avoid.