[PostgreSQL-Hackers] Re: AIX shared libraries (was Re: [PATCHES] Fix linking of OpenLDAP libraries)

AIX 4.3 is the first version to support the -brtl. The current code is
in place to mimic the behaviour of dlopen, etc, on the older platforms.

I think we are at a point that we can stop maintaining AIX older than
4.3 if we want.

-rocco

Version 5.1 is no longer being maintained by IBM; we were some
displeased when we heard when support offerings were expiring :-(.
Fortunately, we already had plans in place for a migration to 5.3.

I have to agree that even 4.3 is "really rather old" now.

Looking at IBM's "support lifecycle" list...
<http://www-306.ibm.com/software/info/supportlifecycle/list/a.html>

AIX version Available Support Withdrawn
-----------------------------------------------------------------
5.1 May 2001 April 2006
5.2 Oct 2002 Sept 2008
5.3 Aug 2004 unannounced, presumably late 2010...

I'd guess that 4.3 fell out of support in late 2004.

Ok, I have spent some time researching and thinking, and I
have three proposals how to deal with linking on AIX.

1) Leave everything as it is and add the LDAP libraries to the
AIX hack in Makefile.shlib.
Pros:
- Little work.
Cons:
- PostgreSQL will continue to be statically linked on AIX (unless
somebody feeds configure the right LDFLAGS).

2) Remove the AIX hack from Makefile.shlib, add -brtl and
-blibpath:"$(rpathdir)":*-L directories in LDPATH*:/usr/lib:/lib
(this sets the AIX equivalent for RPATH) to LDFLAGS for AIX.
Pros:
- Dynamic linking on AIX.
- The organization of the libraries (libpq.a static,
libpq.so dynamic) is similar to other operating systems.
Cons:
- The library organization is counter-intuitive to AIX people,
and most people will inadvertedly link statically when linking
against libpq.
- According to Rocco Altier it will not work on historic
versions of AIX (no -brtl flag).

3) Major hacking in Makefile.shlib to achieve the following:
- libXX.so.n is built from libXX.a in the traditional way.
Then libXX.a is deleted, and recreated as archive
containing libXX.so.n.
- Linking takes place withOUT -brtl, but with -blibpath:...
as in 2).
- When the shared libs are installed, I see two options:
a) copy (and overwrite) libXX.a to libdir, do not
install libXX.so.n
b) Look for existing libXX.a in libdir, extract all
libXX.so.k from it, mark them LOADONLY with
'strip -e libXX.so.k', create a new libXX.a with
these objects and the new libXX.so.n

Pros:
- Dynamic linking on AIX.
- AIX-conforming organization of libraries.
- In the case of 3)b), multiple versions of the library
can be retained in the same archive. Linking is only
possible with the latest versions, but old programs
continue to work.
- 3)a) will probably work on older versions of AIX
(I hope there's a -blibpath flag).
Cons:
- Much work, particularly with 3)b).
- Library organization on AIX will be different from other
platforms.
- 3)b) will probably not work on old versions of AIX
(I read a posting that makes me believe that 'strip -e'
was not around before 4.3.3.

I am willing to implement whatever solution we decide upon.
I personally would prefer 3)a), but am happy with anything
except 1).

Yours,
Laurenz Albe

I personally would prefer 3)a)

Hm. The objection I see to this is that it will not support concurrent
installation of multiple libpq versions. What about

4) Build and install only libXX.so.n, don't install libXX.a at all

5) As 4), plus actively remove any libXX.a seen in the install directory

regards, tom lane

Won't work - the linker looks for libXX.so and won't find
libXX.so.n. If you create a symbolic link
libXX.so --> libXX.so.n, you can link, but the executable will
depend on libXX.so and not on libXX.so.n.

Moreover, you cannot link statically any more because in a
static link only libXX.a files will be searched...
Same problem.

Yours,
Laurenz Albe

Ugh. So given that linker behavior, it's basically impossible to
support multiple libpq versions in the same directory anyway on AIX.

I concur with your 3a) then. Do you have time to do that now?

regards, tom lane

It is possible, if you have both versions of the shared object in
the same library. Essentially what I proposed for 3b).
It is the way IBM does it with their system libraries.

I set up a sample with libpq version 4 and version 5 in libpq.a:

$ dump -ov /postgres/8.2/lib/libpq.a
/postgres/8.2/lib/libpq.a[libpq.so.4]:
***Object Module Header***
[...]
Flags=( EXEC DYNLOAD SHROBJ LOADONLY DEP_SYSTEM )
[...]
/postgres/8.2/lib/libpq.a[libpq.so.5]:
***Object Module Header***
[...]
Flags=( EXEC DYNLOAD SHROBJ DEP_SYSTEM )
[...]

The linker will only link against the shared object that does
not have the LOADONLY flag set, but stuff linked against
libpq.a(libpq.so.4) will continue to work.
I'll start right away.

Yours,
Laurenz Albe