On Tue, Dec 02, 2003 at 11:39:39AM +0100, Didierjean Fabrice wrote:
> Hello,
> 
> I am using amanda 2.4.4p1 on a AIX 4.3.3 IBM RS6000. I have compiled it
> with both, the ibm coompiler en gcc 2.95.3. The both gave me an unusable
> sendsize command. This command end in a coredmp. For some obscure raison
> the executable crash on the call to amroflock, dont know why (seem to be
> a link error ..)
> 
> Well after 1 day, i found a solution. I recompiled all amanda with
> --disable-shared option, and after that all seems to work normaly

That sounds like a shared library is seen at compile-time
but not at run-time.  The "link error" you note (without the
--disable-shared option) is probably the run-time "dynamic
linker" not finding the library that the compiler did find.

Shared libraries are preferable due to better use of memory
and disk space.  One copy of the shared library for all programs
that use it as opposed to a separate, private copy, in each
program.  Think about how many C programs use "printf" and what
a waste it would be if each has a separate, private copy.

I scanned some AIX documentation online - meaning I could have,
and most likely did, miss a lot :((  I'll relate some of what
I found to Solaris which I know better.  Maybe someone who knows
AIX better can correct any omissions or errors.

Most compilers and linkers use a "library search path" to locate
the libraries they need.  There is generally a default set of
directories to search and this can be extended in several ways.
One way, generally considered the preferable way, is with compile/
linker options.  On Solaris some relevant options include:

   -l<library>          # a library that will be needed
   -L<directory>        # a directory for the compiler to search in
   -R<directory>        # a directory for the runtime linker to search

Note, on Solaris the search path is extended separatly for the
compiler and the runtime linker.  My scan of AIX documentation
suggests it only has the "-L" and that it may serve both purposes.

A second, less prefered way, to extend the library search path
is with an environment variable.  On Solaris the appropriate
variable is "LD_LIBRARY_PATH".  My reading of AIX stuff suggests
the compareable variable there is "LIBPATH".  The setting of this
variable could be a source of your troubles when using shared libs.
It may be set one way during compile, but when amanda runs it from
cron it may be different.  That is one reason for prefering to
set the compile and runtime paths in the executable with the -L
(and maybe -R) options.

Solaris also has one command that I did not find a comparable one
on AIX.  That is the "ldd" command.  It looks at an executable
file and lists the shared libraries it needs and where it finds
them (or doesn't find them).  Here is an example:

  $ ldd firebird-bin
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libglib-1.2.so.0 =>      /usr/sfw/lib/libglib-1.2.so.0
        libc.so.1 =>     /usr/lib/libc.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libmozjs.so =>   (file not found)
        libX11.so.4 =>   /usr/lib/libX11.so.4
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libm.so.1 =>     /usr/lib/libm.so.1
        libCstd.so.1 =>  /usr/lib/libCstd.so.1
        libxpcom.so =>   (file not found)
        libpthread.so.1 =>       /usr/lib/libpthread.so.1
        libgtk-1.2.so.0 =>       /usr/sfw/lib/libgtk-1.2.so.0

This output says most of the libs will be found at run-time.
But two libs (libmozjs.so and libxpcom.so) were found properly
during compile, but at run-time they will not be found.
This executable may run ok until something in the "not found"
libraries is needed.

If I've compiled this executable I go back and set the appropriate
options so the run-time linker finds the libraries.  Otherwise,
as above where I did not compile the program, I run it from a
wrapper shell that first sets LD_LIBRARY_PATH (your LIBPATH)
appropriately and then calls the actual executable.

As I noted, I did not find a program compareable to ldd in my
scan of AIX docs.  There probably is one.  It would be a good
diagnostic tool to put into your toolkit.

jl
-- 
Jon H. LaBadie                  jon AT jgcomp DOT com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)