bug-gnulib
[Top][All Lists]
Advanced

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

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


From: CHIGOT, CLEMENT
Subject: Re: [PATCH] m4: fix --disable-rpath for AIX
Date: Mon, 17 Feb 2020 09:40:18 +0000

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. 




reply via email to

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