Using -blibpath to AIX-Samba generation with xlc
aabox2k at yahoo.com
Tue Nov 7 18:01:47 GMT 2006
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)
(from the loader section)
***Import File Strings***
INDEX PATH BASE MEMBER
(taken from make -n bin/smbd)
(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:
... 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
- 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
More information about the samba-technical