Re: AIX shared libraries

Lists: pgsql-hackers
From: "Albe Laurenz" <all(at)adv(dot)magwien(dot)gv(dot)at>
To: <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <RoccoA(at)Routescape(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: AIX shared libraries
Date: 2006-09-14 09:45:23
Message-ID: 52EF20B2E3209443BC37736D00C3C1380A593971@EXADV1.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Tom Lane wrote:
>>> I think there's a reasonable argument that by installing
>>> a .a file that isn't a shared library, we are violating
>>> the platform's conventions.
>
> Hm. This seems possible with some moderate hacking on Makefile.shlib
> (certainly it'd be no more invasive than the existing Windows-specific
> platform variants). [...]
>
> Another issue with installing only .a is that there's no provision
> for versioning in .a library names ... what happens to someone who
> needs two generations of libpq on his machine?

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)


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Albe Laurenz" <all(at)adv(dot)magwien(dot)gv(dot)at>
Cc: RoccoA(at)Routescape(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: AIX shared libraries
Date: 2006-09-14 14:03:13
Message-ID: 28608.1158242593@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

"Albe Laurenz" <all(at)adv(dot)magwien(dot)gv(dot)at> writes:
> I personally would prefer 3)a)

> 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

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