openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#7877) please make gcrypt optional with newer gnutls
by ryan＠nardis.ca 23 Jun '14

23 Jun '14

--047d7bdc8ac419e30c04fc856540 Content-Type: text/plain; charset=UTF-8 And here are the changes for smbk5pwd. Tried to use gnutls' own api since it abstracts gcrypt/nettle, but sadly it doesn't provide md4, so nettle it is. Note this patch assumes the HAVE_GNUTLS_GCRYPT define from the configure addition in the previous patch. --047d7bdc8ac419e30c04fc856540 Content-Type: text/x-patch; charset=US-ASCII; name="0001-ITS-7877-support-nettle-in-smbk5pwd.patch" Content-Disposition: attachment; filename="0001-ITS-7877-support-nettle-in-smbk5pwd.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hws5388e1 RnJvbSAwMTU3Nzc4OTM3NTZiMjEwZGVlN2Q0MDA2ZWM0ZGVmMDEwMTQ0NTE2IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBSeWFuIFRhbmR5IDxyeWFuQG5hcmRpcy5jYT4KRGF0ZTogTW9u LCAyMyBKdW4gMjAxNCAxMToxOToyNiAtMDcwMApTdWJqZWN0OiBbUEFUQ0hdIElUUyM3ODc3IHN1 cHBvcnQgbmV0dGxlIGluIHNtYms1cHdkCgotLS0KIGNvbnRyaWIvc2xhcGQtbW9kdWxlcy9zbWJr NXB3ZC9zbWJrNXB3ZC5jIHwgMzAgKysrKysrKysrKysrKysrKysrKysrKysrKystLS0tCiAxIGZp bGUgY2hhbmdlZCwgMjYgaW5zZXJ0aW9ucygrKSwgNCBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQg YS9jb250cmliL3NsYXBkLW1vZHVsZXMvc21iazVwd2Qvc21iazVwd2QuYyBiL2NvbnRyaWIvc2xh cGQtbW9kdWxlcy9zbWJrNXB3ZC9zbWJrNXB3ZC5jCmluZGV4IDA3NWNlODguLjZjMDAzMDEgMTAw NjQ0Ci0tLSBhL2NvbnRyaWIvc2xhcGQtbW9kdWxlcy9zbWJrNXB3ZC9zbWJrNXB3ZC5jCisrKyBi L2NvbnRyaWIvc2xhcGQtbW9kdWxlcy9zbWJrNXB3ZC9zbWJrNXB3ZC5jCkBAIC02Niw4ICs2Niwx NSBAQCBzdGF0aWMgT2JqZWN0Q2xhc3MgKm9jX2tyYjVLRENFbnRyeTsKIAogI2lmZGVmIERPX1NB TUJBCiAjaWZkZWYgSEFWRV9HTlVUTFMKLSNpbmNsdWRlIDxnY3J5cHQuaD4KIHR5cGVkZWYgdW5z aWduZWQgY2hhciBERVNfY2Jsb2NrWzhdOworI2lmZGVmIEhBVkVfR05VVExTX0dDUllQVAorI2lu Y2x1ZGUgPGdjcnlwdC5oPgorI2Vsc2UKKy8qIGFzc3VtZSBnbnV0bHMgJiYgIWdjcnlwdCA9PiBu ZXR0bGUgKi8KKyNkZWZpbmUgSEFWRV9HTlVUTFNfTkVUVExFIDEKKyNpbmNsdWRlIDxuZXR0bGUv ZGVzLmg+CisjaW5jbHVkZSA8bmV0dGxlL21kNC5oPgorI2VuZGlmCiAjZWxpZiBIQVZFX09QRU5T U0wKICNpbmNsdWRlIDxvcGVuc3NsL2Rlcy5oPgogI2luY2x1ZGUgPG9wZW5zc2wvbWQ0Lmg+CkBA IC0xOTIsMTIgKzE5OSwxNCBAQCBzdGF0aWMgdm9pZCBsbWhhc2goCiAJREVTX2NibG9jayBoYnVm WzJdOwogI2lmZGVmIEhBVkVfT1BFTlNTTAogCURFU19rZXlfc2NoZWR1bGUgc2NoZWR1bGU7Ci0j ZWxpZiBkZWZpbmVkKEhBVkVfR05VVExTKQorI2VsaWYgZGVmaW5lZChIQVZFX0dOVVRMU19HQ1JZ UFQpCiAJZ2NyeV9jaXBoZXJfaGRfdCBoID0gTlVMTDsKIAlnY3J5X2Vycm9yX3QgZXJyOwogCiAJ ZXJyID0gZ2NyeV9jaXBoZXJfb3BlbiggJmgsIEdDUllfQ0lQSEVSX0RFUywgR0NSWV9DSVBIRVJf TU9ERV9DQkMsIDAgKTsKIAlpZiAoIGVyciApIHJldHVybjsKKyNlbGlmIGRlZmluZWQoSEFWRV9H TlVUTFNfTkVUVExFKQorCXN0cnVjdCBkZXNfY3R4IGN0eDsKICNlbmRpZgogCiAJc3RybmNweSgg VWNhc2VQYXNzd29yZCwgcGFzc3dkLT5idl92YWwsIDE0ICk7CkBAIC0yMDUsNyArMjE0LDcgQEAg c3RhdGljIHZvaWQgbG1oYXNoKAogCWxkYXBfcHZ0X3N0cjJ1cHBlciggVWNhc2VQYXNzd29yZCAp OwogCiAJbG1QYXNzd2RfdG9fa2V5KCBVY2FzZVBhc3N3b3JkLCAma2V5ICk7Ci0jaWZkZWYgSEFW RV9HTlVUTFMKKyNpZmRlZiBIQVZFX0dOVVRMU19HQ1JZUFQKIAllcnIgPSBnY3J5X2NpcGhlcl9z ZXRrZXkoIGgsICZrZXksIHNpemVvZihrZXkpICk7CiAJaWYgKCBlcnIgPT0gMCApIHsKIAkJZXJy ID0gZ2NyeV9jaXBoZXJfZW5jcnlwdCggaCwgJmhidWZbMF0sIHNpemVvZihrZXkpLCAmU3RkVGV4 dCwgc2l6ZW9mKGtleSkgKTsKQEAgLTIxOSw2ICsyMjgsMTMgQEAgc3RhdGljIHZvaWQgbG1oYXNo KAogCQl9CiAJCWdjcnlfY2lwaGVyX2Nsb3NlKCBoICk7CiAJfQorI2VsaWYgZGVmaW5lZChIQVZF X0dOVVRMU19ORVRUTEUpCisJZGVzX3NldF9rZXkoICZjdHgsICZrZXkgKTsKKwlkZXNfZW5jcnlw dCggJmN0eCwgc2l6ZW9mKGtleSksICZoYnVmWzBdLCAmU3RkVGV4dCApOworCisJbG1QYXNzd2Rf dG9fa2V5KCAmVWNhc2VQYXNzd29yZFs3XSwgJmtleSApOworCWRlc19zZXRfa2V5KCAmY3R4LCAm a2V5ICk7CisJZGVzX2VuY3J5cHQoICZjdHgsIHNpemVvZihrZXkpLCAmaGJ1ZlsxXSwgJlN0ZFRl eHQgKTsKICNlbGlmIGRlZmluZWQoSEFWRV9PUEVOU1NMKQogCWRlc19zZXRfa2V5X3VuY2hlY2tl ZCggJmtleSwgc2NoZWR1bGUgKTsKIAlkZXNfZWNiX2VuY3J5cHQoICZTdGRUZXh0LCAmaGJ1Zlsw XSwgc2NoZWR1bGUgLCBERVNfRU5DUllQVCApOwpAQCAtMjQzLDYgKzI1OSw4IEBAIHN0YXRpYyB2 b2lkIG50aGFzaCgKIAljaGFyIGhidWZbSEFTSExFTl07CiAjaWZkZWYgSEFWRV9PUEVOU1NMCiAJ TUQ0X0NUWCBjdHg7CisjZWxpZiBkZWZpbmVkKEhBVkVfR05VVExTX05FVFRMRSkKKwlzdHJ1Y3Qg bWQ0X2N0eCBjdHg7CiAjZW5kaWYKIAogCWlmIChwYXNzd2QtPmJ2X2xlbiA+IE1BWF9QV0xFTioy KQpAQCAtMjUyLDggKzI3MCwxMiBAQCBzdGF0aWMgdm9pZCBudGhhc2goCiAJTUQ0X0luaXQoICZj dHggKTsKIAlNRDRfVXBkYXRlKCAmY3R4LCBwYXNzd2QtPmJ2X3ZhbCwgcGFzc3dkLT5idl9sZW4g KTsKIAlNRDRfRmluYWwoICh1bnNpZ25lZCBjaGFyICopaGJ1ZiwgJmN0eCApOwotI2VsaWYgZGVm aW5lZChIQVZFX0dOVVRMUykKKyNlbGlmIGRlZmluZWQoSEFWRV9HTlVUTFNfR0NSWVBUKQogCWdj cnlfbWRfaGFzaF9idWZmZXIoR0NSWV9NRF9NRDQsIGhidWYsIHBhc3N3ZC0+YnZfdmFsLCBwYXNz d2QtPmJ2X2xlbiApOworI2VsaWYgZGVmaW5lZChIQVZFX0dOVVRMU19ORVRUTEUpCisJbWQ0X2lu aXQoICZjdHggKTsKKwltZDRfdXBkYXRlKCAmY3R4LCBwYXNzd2QtPmJ2X2xlbiwgcGFzc3dkLT5i dl92YWwgKTsKKwltZDRfZGlnZXN0KCAmY3R4LCBzaXplb2YoaGJ1ZiksICh1bnNpZ25lZCBjaGFy ICopaGJ1ZiApOwogI2VuZGlmCiAKIAloZXhpZnkoIGhidWYsIGhhc2ggKTsKLS0gCjIuMC4wCgo= --047d7bdc8ac419e30c04fc856540--

1 0

Re: (ITS#7878) OpenLDAP MinGW Build Problem
by hyc＠symas.com 23 Jun '14

23 Jun '14

ron(a)zytrax.com wrote: > Full_Name: Ron Aitchison > Version: 2.4.39 > OS: Windows 7/MinGW-w64/MSYS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (67.230.141.32) > > > Checked the build error reports before submitting > Building OpenLDAP 2.4.39 under MinGW-w64 (Win32 chain) and MSYS > Configure command > ./configure --prefix=/target LIBS='-lpcre -lgdi32 -lpthread' --enable-overlays > --disable-shared CPPFLAGS='-I/target/include' LDFLAGS='-L/target/lib' > make depend - works > make - fails with undefined uint32_t in /servers/slapd/back-mdm/init.c > Since this works on standard systems it is clearly some artifact of MinGW and/or > configure arguments. Fixed by adding #include <stdint.h> in > /servers/slapd/back-mdm/back-mdm.h. Make then ran to completion and slapd > loaded. Since stdint.h is 'double include' safe there is probably no down-side > to this quick fix. What version of MSYS/Mingw64 are you using? It builds cleanly for me here and has done so for years. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7879) liblmdb "mtest" programs do not build on mingw64
by hyc＠symas.com 23 Jun '14

23 Jun '14

batterseapower(a)hotmail.com wrote: > Full_Name: Max Bolingbroke > Version: LMDB HEAD > OS: Windows > URL: ftp://ftp.openldap.org/incoming/max-bolingbroke-20140622.patch > Submission from: (NULL) (81.111.197.81) > > > srandom/random do not appear to be defined on mingw. The trivial patch in > max-bolingbroke-20140622.patch simply defines these functions to the C standard > equivalents on Windows, which lets LMDB build cleanly there. I've committed a different change. There's no real need to use srandom over srand, and the fewer ifdef's the better. > > I, Maximilian Bolingbroke, hereby place the following modifications to liblmdb > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose with or > without attribution and/or other notice. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7879) liblmdb "mtest" programs do not build on mingw64
by batterseapower＠hotmail.com 22 Jun '14

22 Jun '14

Full_Name: Max Bolingbroke Version: LMDB HEAD OS: Windows URL: ftp://ftp.openldap.org/incoming/max-bolingbroke-20140622.patch Submission from: (NULL) (81.111.197.81) srandom/random do not appear to be defined on mingw. The trivial patch in max-bolingbroke-20140622.patch simply defines these functions to the C standard equivalents on Windows, which lets LMDB build cleanly there. I, Maximilian Bolingbroke, hereby place the following modifications to liblmdb (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7877) please make gcrypt optional with newer gnutls
by ryan＠nardis.ca 21 Jun '14

21 Jun '14

This is a multi-part message in MIME format. --------------010505020103090906040401 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit This might be a better patch, if the build system change is acceptable. --------------010505020103090906040401 Content-Type: text/x-patch; name="0001-ITS-7877-detect-whether-gnutls-uses-gcrypt.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-ITS-7877-detect-whether-gnutls-uses-gcrypt.patch" >From e904900beb419576abc098e96deda04e53119603 Mon Sep 17 00:00:00 2001 From: Ryan Tandy <ryan(a)nardis.ca> Date: Fri, 20 Jun 2014 14:44:23 -0700 Subject: [PATCH] ITS#7877 detect whether gnutls uses gcrypt --- configure.in | 14 ++++++++++++++ libraries/libldap/tls_g.c | 20 ++++++++++++++++++-- 2 files changed, 32 insertions(+), 2 deletions(-) diff --git a/configure.in b/configure.in index 84bfc8a..27fe13a 100644 --- a/configure.in +++ b/configure.in @@ -1223,6 +1223,20 @@ if test $ol_link_tls = no ; then fi fi +if test $ol_with_tls = gnutls ; then + AC_CHECK_HEADERS(gcrypt.h) + + if test $ac_cv_header_gcrypt_h = yes ; then + AC_CHECK_LIB(gnutls, gcry_cipher_open, + [have_gnutls_gcrypt=yes], [have_gnutls_gcrypt=no]) + + if test $have_gnutls_gcrypt = yes ; then + AC_DEFINE(HAVE_GNUTLS_GCRYPT, 1, + [define if GnuTLS is using GCrypt]) + fi + fi +fi + dnl NOTE: caller must specify -I/path/to/nspr4 and -I/path/to/nss3 dnl and -L/path/to/nspr4 libs and -L/path/to/nss3 libs if those libs dnl are not in the default system location diff --git a/libraries/libldap/tls_g.c b/libraries/libldap/tls_g.c index ee83b5c..417c768 100644 --- a/libraries/libldap/tls_g.c +++ b/libraries/libldap/tls_g.c @@ -43,10 +43,16 @@ #include <gnutls/gnutls.h> #include <gnutls/x509.h> -#include <gcrypt.h> #if LIBGNUTLS_VERSION_NUMBER >= 0x020200 #define HAVE_CIPHERSUITES 1 +#else +#undef HAVE_CIPHERSUITES +#endif + +#ifdef HAVE_GNUTLS_GCRYPT +#include <gcrypt.h> +#if LIBGNUTLS_VERSION_NUMBER >= 0x020200 /* This is a kludge. gcrypt 1.4.x has support. Recent GnuTLS requires gcrypt 1.4.x * but that dependency isn't reflected in their configure script, resulting in * build errors on older gcrypt. So, if they have a working build environment, @@ -54,9 +60,9 @@ */ #define HAVE_GCRYPT_RAND 1 #else -#undef HAVE_CIPHERSUITES #undef HAVE_GCRYPT_RAND #endif +#endif #ifndef HAVE_CIPHERSUITES /* Versions prior to 2.2.0 didn't handle cipher suites, so we had to @@ -143,6 +149,15 @@ tlsg_mutex_unlock( void **lock ) return ldap_pvt_thread_mutex_unlock( *lock ); } +#if GNUTLS_VERSION_NUMBER >= 0x020b00 +tlsg_thr_init( void ) +{ + gnutls_global_set_mutex (tlsg_mutex_init, + tlsg_mutex_destroy, + tlsg_mutex_lock, + tlsg_mutex_unlock); +} +#else static struct gcry_thread_cbs tlsg_thread_cbs = { GCRY_THREAD_OPTION_USER, NULL, @@ -158,6 +173,7 @@ tlsg_thr_init( void ) { gcry_control (GCRYCTL_SET_THREAD_CBS, &tlsg_thread_cbs); } +#endif #endif /* LDAP_R_COMPILE */ /* -- 1.9.1 --------------010505020103090906040401--

1 0

(ITS#7878) OpenLDAP MinGW Build Problem
by ron＠zytrax.com 20 Jun '14

20 Jun '14

Full_Name: Ron Aitchison Version: 2.4.39 OS: Windows 7/MinGW-w64/MSYS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (67.230.141.32) Checked the build error reports before submitting Building OpenLDAP 2.4.39 under MinGW-w64 (Win32 chain) and MSYS Configure command ./configure --prefix=/target LIBS='-lpcre -lgdi32 -lpthread' --enable-overlays --disable-shared CPPFLAGS='-I/target/include' LDFLAGS='-L/target/lib' make depend - works make - fails with undefined uint32_t in /servers/slapd/back-mdm/init.c Since this works on standard systems it is clearly some artifact of MinGW and/or configure arguments. Fixed by adding #include <stdint.h> in /servers/slapd/back-mdm/back-mdm.h. Make then ran to completion and slapd loaded. Since stdint.h is 'double include' safe there is probably no down-side to this quick fix.

1 0

(ITS#7877) please make gcrypt optional with newer gnutls
by ryan＠nardis.ca 20 Jun '14

20 Jun '14

Full_Name: Ryan Tandy Version: HEAD OS: Debian unstable URL: Submission from: (NULL) (142.32.208.235) Debian bug report: https://bugs.debian.org/745231 Quoting Andreas Metzler: "given that gmp has been dual-licensed LGPLv3+/GPLv2+ it should be possible to switch openldap over to the newer version of gnutls. Upstream's 0205e83f4670d10ad3c6ae4b8fc5ec1d0c7020c0 lets the Debian package build successfully (including testsuite). However even with patch there is still some work to be done. libraries/libldap/tls_g.c has some gcrypt related code that should be simply unnecessary with gnutls3, therefore it should not link against libgcrypt either. (Except for contrib/slapd-modules/smbk5pwd/smbk5pwd.c)." The following changes make gcrypt optional for libldap. For versions where both nettle and gcrypt are supported, I assume the default since no mechanism is provided for detecting which is actually in use. Tested with GnuTLS 2.8.6 and 3.2.15. --- a/libraries/libldap/tls_g.c +++ b/libraries/libldap/tls_g.c @@ -43,10 +43,17 @@ #include <gnutls/gnutls.h> #include <gnutls/x509.h> -#include <gcrypt.h> #if LIBGNUTLS_VERSION_NUMBER >= 0x020200 #define HAVE_CIPHERSUITES 1 +#else +#undef HAVE_CIPHERSUITES +#endif + +/* gnutls >= 2.11.1 no longer uses gcrypt by default */ +#if LIBGNUTLS_VERSION_NUMBER < 0x020b01 +#include <gcrypt.h> +#if LIBGNUTLS_VERSION_NUMBER >= 0x020200 /* This is a kludge. gcrypt 1.4.x has support. Recent GnuTLS requires gcrypt 1.4.x * but that dependency isn't reflected in their configure script, resulting in * build errors on older gcrypt. So, if they have a working build environment, @@ -54,9 +61,10 @@ */ #define HAVE_GCRYPT_RAND 1 #else -#undef HAVE_CIPHERSUITES #undef HAVE_GCRYPT_RAND #endif +#endif + #ifndef HAVE_CIPHERSUITES /* Versions prior to 2.2.0 didn't handle cipher suites, so we had to @@ -143,6 +151,7 @@ tlsg_mutex_unlock( void **lock ) return ldap_pvt_thread_mutex_unlock( *lock ); } +#if GNUTLS_VERSION_NUMBER <= 0x020b00 static struct gcry_thread_cbs tlsg_thread_cbs = { GCRY_THREAD_OPTION_USER, NULL, @@ -158,6 +167,16 @@ tlsg_thr_init( void ) { gcry_control (GCRYCTL_SET_THREAD_CBS, &tlsg_thread_cbs); } +#else +static void +tlsg_thr_init( void ) +{ + gnutls_global_set_mutex (tlsg_mutex_init, + tlsg_mutex_destroy, + tlsg_mutex_lock, + tlsg_mutex_unlock); +} +#endif #endif /* LDAP_R_COMPILE */ /* I have not looked at smbk5pwd yet.

1 0

Re: (ITS#5184) pkg-config file for libraries
by bj＠sernet.de 17 Jun '14

17 Jun '14

On 2014-06-17 at 12:36 -0700 Howard Chu sent off: > If you're depending on some unknown OpenLDAP install to provide all > of the features that your Samba package needs, you need more than > luck. You need to know that it was built against a compatible > Kerberos library, a sane Cyrus SASL version, and a working crypto > library. The only way to know that is to build it yourself against > valid packages, in which case, you don't need to go grubbing through > the system looking for them. many people are happy with their own installation of openldap or whatever package. Also I know what we have to check for to have a sufficient ldap implementation for our Samba builds, believe me :-) > If you're depending on some OpenLDAP that was packaged by someone > else, then you should be asking them to provide a pkg-config file > for their package. Installation issues are strictly not our concern, > we distribute source code. That should have already been clear from > http://www.openldap.org/its/index.cgi/Archive.Build?id=5184 Followup okay, I didn't explicitly write that I disagree. I disgree on that statement by the way :-) usually package maintainers don't write .pc files they install the .pc files that the source code ships. We also ship .pc files for all of our libraries we ship in Samba. "make install" puts in the right content. > 1. > > Even if we provided a .pc file, you still have to guess where *that* > got installed - was it in /usr, or in /usr/local, or somewhere else? to get the location of the pkg-config file is really the smallest pain. > I've certainly never seen pkg-config as a standard component of AIX > or Solaris. What difference does it make here if pkg-config is a *standard* component or if it has to be separately installed? > > Is pkg-config even supported on AIX? it is, google "pkg-config aix" shows you. To have a pkg-config files is something openldap *benefits* from because it ensures that people can build agains openldap without big trouble. I'm not sure if you really see how much benefit openldap gets out of those trivial to generate .pc files actually. If people are able to build against mozldap because just because there is a simple .pc file which sets the compile and link flags right, then mozldap might become their prefered library in the future. It's up to you if you want to make it easy or hard for people to use your software. Cheers Björn

1 0

Re: (ITS#5184) pkg-config file for libraries
by hyc＠symas.com 17 Jun '14

17 Jun '14

Björn JACKE wrote: > On 2014-06-17 at 07:04 -0700 Howard Chu sent off: >> bj(a)sernet.de wrote: >>> for Samba we really have some pain to get the right compile and linker flags >>> for different architectures, especially there, where OpenLDAP is not a >>> first-class citizen like on AIX. >>> >>> mozldap offers pkg-config files which we will start to use in Samba soon. It >>> would be great if OpenLDAP would offer a pkg-config file also to not have to >>> make wild guesses which linker/compile flags and which paths to use. >> >> I don't see the problem. There are no special compiler or linker >> flags for applications to use libldap. > > if you build on a system where you don't know what LDAP library you have you > exactly have to test for the existing header files, you have to test for the > libs that you find in the library search paths (and maybe also in > library paths that are not in the search path), you have to look for > existing symbols to know which exact flavor of the lib you have, you > have to use the right include paths. All those things that you have to > look up, have to fit together also. If you are LUCKY they will fit together on > an AIX or on a Solaris box. If not, you use the right header files but the > wrong linker flags, there are many things to screw up. It is a huge bunch of > work to get all this information pieces together and puzzle them right for your > build system. In Samba we had have a hard time to do that in the past and with > the new waf base build system we have to fix a lot that was working before. The > LDAP libaries (also OpenLDAP on Unix systems...) have always been a major pain > for the build system and a pkg-config file, which we can just use to get the > right compiler and linker flags would be a great help for that and it > would make the build agains openldap much more predictable and stable. > If you're depending on some unknown OpenLDAP install to provide all of the features that your Samba package needs, you need more than luck. You need to know that it was built against a compatible Kerberos library, a sane Cyrus SASL version, and a working crypto library. The only way to know that is to build it yourself against valid packages, in which case, you don't need to go grubbing through the system looking for them. If you're depending on some OpenLDAP that was packaged by someone else, then you should be asking them to provide a pkg-config file for their package. Installation issues are strictly not our concern, we distribute source code. That should have already been clear from http://www.openldap.org/its/index.cgi/Archive.Build?id=5184 Followup 1. Even if we provided a .pc file, you still have to guess where *that* got installed - was it in /usr, or in /usr/local, or somewhere else? I've certainly never seen pkg-config as a standard component of AIX or Solaris. Is pkg-config even supported on AIX? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5184) pkg-config file for libraries
by bj＠sernet.de 17 Jun '14

17 Jun '14

On 2014-06-17 at 07:04 -0700 Howard Chu sent off: > bj(a)sernet.de wrote: > >for Samba we really have some pain to get the right compile and linker flags > >for different architectures, especially there, where OpenLDAP is not a > >first-class citizen like on AIX. > > > >mozldap offers pkg-config files which we will start to use in Samba soon. It > >would be great if OpenLDAP would offer a pkg-config file also to not have to > >make wild guesses which linker/compile flags and which paths to use. > > I don't see the problem. There are no special compiler or linker > flags for applications to use libldap. if you build on a system where you don't know what LDAP library you have you exactly have to test for the existing header files, you have to test for the libs that you find in the library search paths (and maybe also in library paths that are not in the search path), you have to look for existing symbols to know which exact flavor of the lib you have, you have to use the right include paths. All those things that you have to look up, have to fit together also. If you are LUCKY they will fit together on an AIX or on a Solaris box. If not, you use the right header files but the wrong linker flags, there are many things to screw up. It is a huge bunch of work to get all this information pieces together and puzzle them right for your build system. In Samba we had have a hard time to do that in the past and with the new waf base build system we have to fix a lot that was working before. The LDAP libaries (also OpenLDAP on Unix systems...) have always been a major pain for the build system and a pkg-config file, which we can just use to get the right compiler and linker flags would be a great help for that and it would make the build agains openldap much more predictable and stable.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs