On May 15, 2009, at 07:11, miguel.sand...@arcelormittal.com wrote: > Moreover, since you're on AIX, adding -lsomelib as a XLC argument > expects to find an archive libsomelib.a and not an object file. > So you will have to archive the shared libraries with ar. > > F.e. > The built created the shared library gssapi_krb5.so (which is in AIX > a bad name for a shared library, all libraries (static/shared) > should end with .o) > Archive it: > # ar -v -q gssapi_krb5.a gssapi_krb5.so
If I recall correctly, earlier versions of AIX at least had a compiler option telling it to look for the .so files instead. However, that would mean that you always have to use this option when building application programs as well. Once upon a time, we built the shared libraries with .a suffixes using ar as above. This was changed some time ago -- I think maybe to let us build both static and shared versions of the libraries at once, though I'm not sure that was the reason, and we don't support building static versions of the installed libraries on any platform any more. So it may have been a mistake, and it might be a good idea to consider reverting that change, though it would mean another ABI change on AIX. Straightening this out requires AIX expertise (or at least the ability to read the documentation plus the experience to say which approach work better overall for AIX developers and system maintainers, factoring in backwards compatibility and versioning and such) plus hardware to test changes on. MIT's test AIX machine died some years ago, and it was running an old version of the OS even then. I assume you meant to write "libgssapi_krb5" above? For shared libraries, we build the individual object files with a .so suffix for mostly historical reasons -- so static and shared libraries could be built in the same directory, on platforms where they have to be compiled with different options (unlike AIX). So "gssapi_krb5.so" is the object file compiled from "gssapi_krb5.c"; libgssapi_krb5.* is the linked or archive forms of the library, and the similarity to the name of one of the source/object files is accidental. -- Ken Raeburn / raeb...@mit.edu / no longer at MIT Kerberos Consortium ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos