| Lists: | pgsql-hackerspgsql-patches |
|---|
| From: | "Albe Laurenz" <all(at)adv(dot)magwien(dot)gv(dot)at> |
|---|---|
| To: | <pgsql-patches(at)postgresql(dot)org>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Fix linking of OpenLDAP libraries |
| Date: | 2006-08-21 13:57:43 |
| Message-ID: | 52EF20B2E3209443BC37736D00C3C13809FB5BB7@EXADV1.host.magwien.gv.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers pgsql-patches |
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 thread safety, OpenLDAP comes with a second
library libldap_r. The thread safe API is identical to
the normal API, the difference is that you must link
against libldap_r instead of libldap to get thead safety.
These are my problems:
- While libpq should be thread safe when ./configured with
--enable_thread_safety, the backend should be linked
against the normal libldap.
- At least on RedHat Linux, you need to link against the
pthread library too if you want to link against libldap_r,
because the latter has unresolved dependencies.
My solution:
- If thread safety is not desired, I link against libldap.
No problem.
- If thread safety is desired, I first try to link against
libldap_r without the thread libraries, and only if that
fails add the thread libraries to LIBS.
- I tweak src/backend/Makefile so that it strips libldap_r
and the thread libs from LIBS and replace it with
libldap if necessary.
That means that if --enable_thread_safety and --with-ldap
is both specified, all executables except 'postgres' will
be linked against libldap_r (and the thread libs, if
necessary).
I tested my patch on RedHat Enterprise Linux 3 and AIX 5.3.
The behaviour for Windows (use the native WLDAP32.DLL)
is unchanged.
Yours,
Laurenz Albe
| Attachment | Content-Type | Size |
|---|---|---|
| ldaplink.patch | application/octet-stream | 4.5 KB |
| 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: | pgsql-patches(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [HACKERS] Fix linking of OpenLDAP libraries |
| Date: | 2006-09-04 19:41:33 |
| Message-ID: | 11268.1157398893@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers pgsql-patches |
"Albe Laurenz" <all(at)adv(dot)magwien(dot)gv(dot)at> 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 removed even if needed for other libraries.
It would probably be safer not to put LDAP into LIBS at all, but invent
two new macros for configure to set, say LDAP_LIBS and LDAP_LIBS_R,
and add these to the link lines in the backend and libpq respectively.
regards, tom lane