Using -blibpath to AIX-Samba generation with xlc

William Jojo jojowil at hvcc.edu
Tue Nov 7 13:34:39 GMT 2006



On Tue, 7 Nov 2006, Andras Atzel wrote:

> Hi Everybody,
>
> we met an interesting problem these days.
> 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'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)



> 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.

> Couldn't it be a good decision to separate LDFLAGS in the scripts to two sections: 'cumulative' and 'non-cumulative'?
> (They could be defined separately, like CLDFLAGS and NCLDFLAGS , or with any other name.)
> The first would contain all the flags like -L<dir> and any other (linker) options that can be defined multiple times on the command line.
> The second would be kept as it is defined at calling up the samba configure.
> The two parts would be joined only in the command line of the compiler/linker.
>
> This splitting would enable a clear definition of the path, where the runtime libraries are searched.
> If there are several such directories, they could be listed in the desired order, all the directories only once.
>
> What is your opinion about this idea?
>

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


Cheers,

Bill

> Cheers
>
> Andras
>
>
>
>
>
>
>


More information about the samba-technical mailing list