Using -blibpath to AIX-Samba generation with xlc

[Andras Atzel]

Hi Bill!

Thanks for your hints!

>> Some samba codes generated in AIX environment, did not start, complaining on missing dynamic libraries.
>> The codes were built using the -blibpath option of the xlc compiler, that enable an effective separation of
>> libraries used by the Samba code and those used by other programs by modifying the loader section of the output file.
>>
>> Checking the command line calling up the xlc compiler/linker it looks, that though only one path was defined
>> (as LDFLAGS= ) for configuration, the command contains several different -blibpath:<path> chunks, some of them
>> multiplied (i counted altogether 5!).

> When you use "-L" it should go to the head of the list. What often happens 
> is someone sets LIBPATH after these things are built. This is where it 
> gets interesting.

> What is output of the following after you compile your product:

> dump -n /path/to/bin | head -25
> ldd /path/to/bin
> unset LIBPATH
> ldd /path/to/bin

*************************
I made this test first on the machine where the problem was detected. ldd pours out about
a dozen libs in /usr/local/lib and /usr/lib and the loader section (now, after the correction)
contains these paths in the right order.
(/usr/local/lib first and if no dedicated library exists, go to standard /usr/lib)
Details:
(from the loader section)
                        ***Import File Strings***
INDEX  PATH                          BASE                MEMBER
0      /usr/local/lib:/usr/local/ssl/lib:/usr/lib

(taken from make -n bin/smbd)
-blibpath:/usr/local/lib::/usr/lib:/lib
-blibpath:/usr/local/lib:/usr/local/ssl/lib:/usr/lib
-blibpath:/usr/local/lib:/usr/local/ssl/lib:/usr/lib
-blibpath:/usr/local/lib::/usr/lib:/lib
-blibpath:/usr/local/lib:/usr/local/ssl/lib:/usr/lib
-blibpath:/usr/local/lib::/usr/lib:/lib
-blibpath:/usr/local/lib:/usr/local/ssl/lib:/usr/lib
(yes, 7 -blibpath was poured together and mixed for a cocktail in configure, though only one

export LDFLAGS="-blibpath:/usr/local/lib:/usr/local/ssl/lib:/usr/lib -L/usr/local/lib"

was given for configure )

Formerly it was:
-blibpath:/usr/local/lib::/usr/lib:/lib
-blibpath:/usr/lib:/usr/local/lib:/usr/local/ssl/lib
-blibpath:/usr/local/lib:/usr/local/ssl/lib:/usr/lib
-blibpath:/usr/local/lib::/usr/lib:/lib 
-blibpath:/usr/lib:/usr/local/lib:/usr/local/ssl/lib
-blibpath:/usr/local/lib::/usr/lib:/lib
-blibpath:/usr/lib:/usr/local/lib:/usr/local/ssl/lib
 ... and it resulted a failure, because and older libiconv version was found in the standard directory.



In the other build used for package, the loader section contains:
INDEX  PATH                          BASE                MEMBER
0      /usr/lib/samba/extra:/usr/lib:/usr/local/lib
    - using the dir /usr/lib/samba/extra to contain all libraries dedicated to Samba-usage
and shipped within the package.


> I'll bet that the runtime loader knows just where to find stuff, but fails 
> since LIBPATH is set. Any chance this is hurling on libiconv? No member 
> libiconv.so.2 in /usr/lib/libiconv.a? (please correct me with additional 
> info if that's not the case)

No LIBPATH was set at all. The loader section was set falsely.
(No member libiconv.so.2 in /usr/lib/libiconv.a? Correct. Exactly that happened (see above)).

>> The cumulative result of these chunks is hardly predictable. We detected this hasard by chance with a test configuration. Until now we had luck and the package runs smoothly. The risk can be minimized by consequently putting the common directory to the first place in the -blibpath chain of _all_ subsystems, that will contain the necessary libraries at runtime.
>>
>> The problem comes from the fact, that the configure scripts regard all LDFLAGS repeatable. So before building Samba, LDFLAGS from previously built subsystems are poured together, that doesn't mean a problem for options, like -L<library_path> for static linking, but -blibpath behaves differently. Apparently the last definition prevails and invalidates all previous appearance of the option.
>>

> That's correct. Many library packages will tell you to use -Wl,-blibpath 
> to link, but I find that -L's strung together work better and also assist 
> the configure utility to find libraries.

AFAIK the 2 solutions are not identical. I use a server for package building that i must share with others, so i put all libraries
necessary for Samba to temporary dirs, that are not identical with the ones on the customer's future machine. So with -blibpath i can
specify still not existing directories with higher priority, than the current ones. I have bad experiences about the
usability of -L with dynamic libraries.

> I'm not sure this will help. Ultimately you need to control your build 
> environment and subsequently your runtime.

Anyway, i would be satisfied if i would see only one -blibpath entry in the 'make -n bin/smbd'.

Thanks for your help
Andras