Kerberos linking on AIX 6.1

[miguel.sanders@arcelormittal.com]

Hi Ken

I just made a typo (I meant libgssapi_krb5.a, sorry for that).
A few remarks:
On AIX, you cannot see from the object file whether it is static or shared. For that you have to examine the XCOFF header. As a general convention in AIX all objects (static/shared) have the ".o" extension. Searching for objects and libraries on AIX at link-time differs a bit from what is observed on other UNIX systems.
F.e. let's say we have a shared object foo.o which is required at link-time for main.c
Three ways to do it 
1) absolute path
# cc main.c /someabsolutepath/foo.o
2) relative path
# cc main.c ../../../foo.o
3) If it is located in the same folder as main.c
# cc main.c foo.o

The main difference between the three options is that the generated executable will have a path component for the dependant shared object foo.o in the XCOFF header (which makes its location fixed for this executable). The same applies for libraries actually. If we were to create an archive libfoo.a which contains foo.o, compiling/linking would go like:
1) absolute path
# cc main.c /someabsolutepath/libfoo.a
2) relative path
# cc main.c ../../../libfoo.a
3) -L / -l linker flags
# cc main.c -L/someabsolutepath -lfoo

If wanted, I'm willing to participate on this.
 

Met vriendelijke groet
Best regards
Bien à vous

Miguel SANDERS
ArcelorMittal Gent

UNIX Systems & Storage
IT Supply Western Europe | John Kennedylaan 51
B-9042 Gent

T +32 9 347 3538 | F +32 9 347 4901 | M +32478 805 023
E miguel.sanders at arcelormittal.com
www.arcelormittal.com/gent

-----Oorspronkelijk bericht-----
Van: Ken Raeburn [mailto:raeburn at MIT.EDU] 
Verzonden: vrijdag 15 mei 2009 16:19
Aan: SANDERS Miguel
CC: luke.scharf at clusterbee.net; kerberos at mit.edu
Onderwerp: Re: Kerberos linking on AIX 6.1

On May 15, 2009, at 07:11, miguel.sanders at 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 / raeburn at mit.edu / no longer at MIT Kerberos Consortium

**** 
This message and any attachment are confidential, intended solely for the use of the individual or entity to whom it is addressed and may be protected by professional secrecy or intellectual property rights. 
If you have received it by mistake, or are not the named recipient(s), please immediately notify the sender and delete the message. You are hereby notified that any unauthorized use, copying or dissemination of any or all information contained in this message is prohibited. 
Arcelormittal shall not be liable for the message if altered, falsified, or in case of error in the recipient. 
This message does not constitute any right or commitment for ArcelorMittal except when expressly agreed otherwise in writing in a separate agreement.  
****