Tom Lane wrote:
The natural way in AIX would be:
- Create libpq.so
- Create libpq.a by 'rm -f libpq.a; ar -rc libpq.a libpq.so'
- Install only libpq.a
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). However, looking at what's already in
Makefile.shlib for AIX makes me doubt the above claim a bit, because
AFAICS libpq.so is produced from libpq.a on that platform. Is it
possible that the rules have changed across AIX versions, and that the
code in there now is needful for older versions?
I don't think that this behaviour has changed. I remember it from
AIX 4.3.2.

Of course libpq.so is created from (the static) libpq.a.
But once you have the dynamic library, you can link statically
against it.
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?
Use different directories and set LIBPATH?
I don't know if there is a canonical way to do that. I'll investigate.

Yours,
Laurenz Albe

Search Discussions

  • Rocco Altier at Sep 13, 2006 at 3:17 pm

    Tom Lane wrote:
    Is it
    possible that the rules have changed across AIX versions,
    and that the code in there now is needful for older versions?
    I don't think that this behaviour has changed. I remember it from
    AIX 4.3.2.
    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
  • Chris Browne at Sep 13, 2006 at 6:04 pm

    "Rocco Altier" writes:
    Tom Lane wrote:
    Is it
    possible that the rules have changed across AIX versions,
    and that the code in there now is needful for older versions?
    I don't think that this behaviour has changed. I remember it from
    AIX 4.3.2.
    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.
    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.
    --
    let name="cbbrowne" and tld="linuxdatabases.info" in String.concat "@" [name;tld];;
    http://linuxfinances.info/info/
    "Of course 5 years from now that will be different, but 5 years from
    now everyone will be running free GNU on their 200 MIPS, 64M
    SPARCstation-5." -- Andrew Tanenbaum, 1992.
  • Albe Laurenz at Sep 14, 2006 at 9:45 am

    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)
  • Tom Lane at Sep 14, 2006 at 2:03 pm

    "Albe Laurenz" <all@adv.magwien.gv.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
  • Albe Laurenz at Sep 14, 2006 at 2:25 pm

    Tom Lane wrote:
    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
    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...
    5) As 4), plus actively remove any libXX.a seen in the
    install directory
    Same problem.

    Yours,
    Laurenz Albe
  • Tom Lane at Sep 14, 2006 at 2:46 pm

    "Albe Laurenz" <all@adv.magwien.gv.at> writes:
    Tom Lane wrote:
    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
    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.
    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
  • Albe Laurenz at Sep 15, 2006 at 6:53 am

    Tom Lane wrote:
    Ugh. So given that linker behavior, it's basically impossible to
    support multiple libpq versions in the same directory anyway on AIX.
    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 concur with your 3a) then. Do you have time to do that now?
    I'll start right away.

    Yours,
    Laurenz Albe

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedSep 12, '06 at 4:12p
activeSep 15, '06 at 6:53a
posts8
users4
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase