Shared libraries have the extension of .so (shared object).
Libraries used to compile applications have the extension .a (archive).
Mike
> Shared libraries in AIX have the extension .a. How is a static library
> named in AIX.
Also with .a extension.
On aix, shared library name (encoded into the Loader section)
is a *combination* of library name + member name, and archive
libraries can contain a mixture of "regular" and "shared" objects
(and a mixture of 32 and 64-bit objects).
For example, /usr/lib/libc.a contains:
frexp.o - regular object
itrunc.o - regular object
shr.o - shared object
...
frexp_64.o - regular 64-bit object
itrunc_64.o - regular 64-bit object
shr_64.o - shared 64-bit object.
A 64-bit application would normally depend on "libc.a(shr_64.o)"
shared library.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
> Are there static libraries in AIX?
Depends on what you call a "static library".
If you define it as "archive library" (i.e. manipulated by 'ar' and
having a structure defined in /usr/include/ar.h), then /usr/lib/libc.a
is a static library (containing shared objects inside).
Other archive libraries, e.g. /usr/lib/libm.a contain no shared
objects inside, and act almost exactly the same as archive libraries
on other UNIX systems.
No.
Laurenz Albe
As Lawrence stated, this is incorrect. Conventionally speaking,
an archive has an extension of ".a"; it can be used to collect
files of any type. Conveniently, it has been used to contain
object code (with supporting symbol tables), and the linker knows
how to access it.
On AIX, archives can contain both static and dynamic object code.
It's still an archive, but the linker will either pull out static
object code (as required) or create references to dynamic object
files (which we like to call "modules" on AIX). There's a
naming convention for these archive members (shr.o, etc) but
there's no requirement that they be named thusly. You can also
name a shared module "libfoo.a" on AIX, and the linker will
do the right thing. That doesn't make it an archive, however.
You can also have shared modules be separate files, and use
".so", ".dll", or whatever for a suffix. And use
-blibsuff:<extension> when linking to tell the linker how to
interpret -l options.
I think there's so more info in
http://www.ibm.com/developerworks/eserver/pdfs/aix_ll.pdf
HTH
Why did you rename it? That seems like the wrong thing to do.
You never stated what your real problem is. What do you want to do
and why do you think that renaming the file will help?
What is the output of 'file libxml2.a' ?
What is the output of 'ar -t libxml2.a' ?
Yours,
Laurenz Albe
I wanted to have three libraries out of libxml2.a: libxml2.so,
libxml2.so.2 and libxml2.so.2.6.20. Libxml2.so and libxml2.so.2 are
symbolic links and libxml2.so.2.6.20 is the actual library. I renamed
libxml2.a as libxml2.so, because I am not clear with the naming
convention of .a files. That is, i don't know how to name the physical
library and the symbolic links of .a libraries.
If I rename libxml2.a as libxml2.so I face one problem. There is a
software libxslt, which I am building from its source. It links with
libxml2 library while building. But it is unable link with libxml2.so.
But it links properly with libxml2.a
So libxml2.a is an archive that contains a shared object.
It is inappropriate to rename that to libxml2.so, because names ending
in .so should be reserved for shared objects.
If you REALLY needed the shared object itself, the correct procedure would
be to unarchive it: ar -x libxml2.a
But I doubt that that is what you have to do, because on AIX libxml2.a
is a shared library and should be recognized as such by the linker.
> I wanted to have three libraries out of libxml2.a: libxml2.so,
> libxml2.so.2 and libxml2.so.2.6.20. Libxml2.so and libxml2.so.2 are
> symbolic links and libxml2.so.2.6.20 is the actual library. I renamed
> libxml2.a as libxml2.so, because I am not clear with the naming
> convention of .a files. That is, i don't know how to name the physical
> library and the symbolic links of .a libraries.
> If I rename libxml2.a as libxml2.so I face one problem. There is a
> software libxslt, which I am building from its source. It links with
> libxml2 library while building. But it is unable link with libxml2.so.
> But it links properly with libxml2.a
That is what I would expect as (like the file command above told you)
it is an archive (.a) and not a shared object (.so)).
If libxslt links properly against libxml2.a, what is your problem?
Yours,
Laurenz Albe
If the (shared) library is named libfoo.a, the compiler should be
invoked as
cc|gcc -L <libdir> -l foo -o executable source.c
where <libdir> is the directory containing libfoo.a, if it is not in
a standard directory (/lib or /usr/lib).
If the headers for the foo library are in a nonstandard directory,
you need an additional -I<includedir> directive for compiling.
If you have problems, post the command that fails and the error message.
Yours,
Laurenz Albe
Short answer: yes.
> If the (shared) library is named libfoo.a, the compiler should be
> invoked as
>
> cc|gcc -L <libdir> -l foo -o executable source.c
>
> where <libdir> is the directory containing libfoo.a, if it is not in
> a standard directory (/lib or /usr/lib).
You are welcome to utilize -l and -L to reference an archive
whose name is of the form libfoo.a, where "lib" and ".a" are the
critical elements of the filename. On AIX, you can add the -blibsuff:
option to specific a particular file suffix, too.
Or you can simply specify the filename directly, just like a
normal .o file. It doesn't matter which you choose to use.
> If the (shared) library is named libfoo.a, the compiler should be
> invoked as
>
> cc|gcc -L <libdir> -l foo -o executable source.c
That command will work on AIX, but is *wrong* on just about every
other UNIX. The correct command is:
cc|gcc source.c -L <libdir> -l foo -o executable
To understand why the order of sources/objects and libraries on
the command line matters, read this:
http://webpages.charter.net/ppluzhnikov/linker.html
I was trying not to confuse the original poster...
Laurenz Albe
Oh, sorry ;-)