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
PROTECTED] On Behalf Of Albe Laurenz
Sent: Tuesday, September 12, 2006 9:01 AM
To: Tom Lane *EXTERN*
Cc: pgsql-hackers@postgresql.org
Subject: Re: [PATCHES] [HACKERS] Fix linking of OpenLDAP libraries
Tom Lane wrote:
In our case, we have libpq.a and libpq.so in the same directory,
so
Kevin Brown wrote:
Let me expand a little on some of the peculiarities of
shared libraries on AIX:
- A normal AIX shared library is called libXX.a
It is an 'ar' archive that contains the shared object(s).
Ah, so the problem really boils down to funny naming conventions.
If they use .a
Tom Lane wrote:
In our case, we have libpq.a and libpq.so in the same directory,
so unless you link with -brtl you will get a static link
(because libpq.a is a static library).
I wonder whether we ought to suppress building (or at least
installing)
our .a libraries at all on AIX. Adding
Albe Laurenz [EMAIL PROTECTED] writes:
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.
The natural way in AIX would be:
- Create libpq.so
- Create libpq.a by 'rm -f libpq.a; ar -rc
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
Albe Laurenz [EMAIL PROTECTED] writes:
Tom Lane wrote:
Applied, but without that last part. It builds OK for me on Darwin,
which is moderately picky about that sort of thing, but someone should
try AIX.
It builds fine on AIX 5.3 as long as you tell it to link with
libpq.so. Static builds
Martijn van Oosterhout kleptog@svana.org writes:
Static links are going to require it on every platform, not just AIX.
The question do we want to ask is how easy do we want to make static
linking, because the same treatment will have to apply to -lssl,
-lcrypto, -lkrb5, -lk5crypto and quite
Tom Lane wrote:
It builds fine on AIX 5.3 as long as you tell it to link with
libpq.so. Static builds against libpq.a will fail.
Hm. We have been assuming that AIX's problem is that dynamic
libraries
don't remember their dependencies properly, but maybe the real issue
is
that it prefers
Albe Laurenz [EMAIL PROTECTED] writes:
Let me expand a little on some of the peculiarities of
shared libraries on AIX:
- A normal AIX shared library is called libXX.a
It is an 'ar' archive that contains the shared object(s).
Ah, so the problem really boils down to funny naming conventions.
Tom Lane wrote:
Here is a new patch that replaces the previous one; it adds two
macros LDAP_LIBS_FE and LDAP_LIBS_BE for frontend and backend,
respectively.
I did not only add them to the Makefile for interfaces/libpq,
but also everywhere something is linked against libpq in case
somebody
On Mon, Sep 11, 2006 at 12:13:29PM +0200, Albe Laurenz wrote:
Applied, but without that last part. It builds OK for me on Darwin,
which is moderately picky about that sort of thing, but someone should
try AIX.
It builds fine on AIX 5.3 as long as you tell it to link with
libpq.so.
Here is a new patch that replaces the previous one; it adds two
macros LDAP_LIBS_FE and LDAP_LIBS_BE for frontend and backend,
respectively.
I did not only add them to the Makefile for interfaces/libpq,
but also everywhere something is linked against libpq in case
somebody links static.
Tom Lane wrote:
Albe Laurenz [EMAIL PROTECTED] writes:
Let me expand a little on some of the peculiarities of
shared libraries on AIX:
- A normal AIX shared library is called libXX.a
It is an 'ar' archive that contains the shared object(s).
Ah, so the problem really boils down to
Albe Laurenz [EMAIL PROTECTED] writes:
I did not only add them to the Makefile for interfaces/libpq,
but also everywhere something is linked against libpq in case
somebody links static.
I intensely dislike that part of the patch, but will work on applying
the rest.
If we do need to start
On Fri, Sep 08, 2006 at 03:20:00PM -0400, Tom Lane wrote:
Albe Laurenz [EMAIL PROTECTED] writes:
I did not only add them to the Makefile for interfaces/libpq,
but also everywhere something is linked against libpq in case
somebody links static.
If we do need to start mentioning all of
Albe Laurenz [EMAIL PROTECTED] writes:
Here is a new patch that replaces the previous one; it adds two
macros LDAP_LIBS_FE and LDAP_LIBS_BE for frontend and backend,
respectively.
I did not only add them to the Makefile for interfaces/libpq,
but also everywhere something is linked against
Tom Lane wrote:
I have realized that my modifications in configure.in and
src/interfaces/libpq/Makefile to link libpq against
OpenLDAP are buggy.
Here is a proposed patch to fix it.
[...]
# The backend doesn't need everything that's in LIBS, however
! LIBS := $(filter-out -lz -lreadline
Tom Lane wrote on September 04, 2006:
Albe Laurenz [EMAIL PROTECTED] writes:
# The backend doesn't need everything that's in LIBS, however
! LIBS := $(filter-out -lz -lreadline -ledit -ltermcap -lncurses
-lcurses -lldap_r $(PTHREAD_LIBS), $(LIBS))
This seems pretty risky. What if
Albe Laurenz [EMAIL PROTECTED] writes:
# The backend doesn't need everything that's in LIBS, however
! LIBS := $(filter-out -lz -lreadline -ledit -ltermcap -lncurses -lcurses
-lldap_r $(PTHREAD_LIBS), $(LIBS))
This seems pretty risky. What if PTHREAD_LIBS contains -L switches?
They'd get
I have realized that my modifications in configure.in and
src/interfaces/libpq/Makefile to link libpq against
OpenLDAP are buggy.
Here is a proposed patch to fix it.
I write this to pgsql-hackers too because I want to share
the difficulty I'm facing - maybe somebody has a better
idea.
To handle
21 matches
Mail list logo