openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

Re: (ITS#8483) CMake buildsystem support for LMDB
by hyc＠symas.com 19 Aug '16

19 Aug '16

Ivan Shapovalov wrote: > On 2016-08-20 at 03:32 +0100, Howard Chu wrote: >> intelfx(a)intelfx.name wrote: >>> >>> Full_Name: Ivan Shapovalov >>> Version: LMDB 0.9.18 >>> OS: GNU/Linux >>> URL: ftp://ftp.openldap.org/incoming/ivan-shapovalov-160820.patch >>> Submission from: (NULL) (77.41.63.43) >>> >>> >>> This patch adds a CMake buildsystem for LMDB, side-by-side with >>> existing >>> Makefile. >>> It builds the same targets except coverage tests. >> >> I am not a fan of CMake. Using it requires learning a whole new set >> of >> documentation in addition to knowing the rules of Make. It comes with >> a huge >> footprint of dependencies, and most people using it are misusing it. > > Mastering CMake is a lot easier than just learning to use Make... > If you don't like CMake out of personal motives, please just say so I have said so, right up front: "I am not a fan of CMake." > and don't cover it with made-up reasons. I don't need to make up reasons. I've spent a lot of time working with CMake already. When setting up a new build environment, it is ridiculously hard to debug a broken setup. Crucial information is hidden, and debug/verbose settings and log files don't reveal it. Been there, done that, no thanks. >> If you need to integrate LMDB into a particular CMake-based project, >> it's a >> lot simpler than this. E.g., >> https://github.com/LMDB/bitmonero/blob/master/external/db_drivers/lib >> lmdb/CMakeLists.txt >> >> There's no reason to duplicate the entire Makefile when you're >> embedding LMDB >> into some other project. This also shows the correct way to use CMake >> and >> propagate threads dependencies. > This file does not cover packaging and exporting targets, which is > crucial when building multiple dependent projects in a staging tree (e. > g. cross-compiling stuff). You see, it is easier to have a single > correct build script in the upstream repo than to have many ad-hoc > build scripts in each project, each deficient in its own regard. There is no such thing as a single correct upstream CMake script since different projects have different requirements for how they intend to use their dependencies. Most projects won't need install targets for the utility commands or manpages. Most projects don't need packaging of intermediate dependencies. There's nothing to argue here. This project doesn't use CMake and we won't maintain files for tools we don't use. -- -- 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#8483) CMake buildsystem support for LMDB
by intelfx＠intelfx.name 19 Aug '16

19 Aug '16

--=-Nq65m7sM2GaofoKVHHN0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 2016-08-20 at 03:32 +0100, Howard Chu wrote: > intelfx(a)intelfx.name wrote: > >=20 > > Full_Name: Ivan Shapovalov > > Version: LMDB 0.9.18 > > OS: GNU/Linux > > URL: ftp://ftp.openldap.org/incoming/ivan-shapovalov-160820.patch > > Submission from: (NULL) (77.41.63.43) > >=20 > >=20 > > This patch adds a CMake buildsystem for LMDB, side-by-side with > > existing > > Makefile. > > It builds the same targets except coverage tests. >=20 > I am not a fan of CMake. Using it requires learning a whole new set > of=C2=A0 > documentation in addition to knowing the rules of Make. It comes with > a huge=C2=A0 > footprint of dependencies, and most people using it are misusing it. Mastering CMake is a lot easier than just learning to use Make... >=20 > >=20 > > Rationale for this change: CMake simplifies building of LMDB with > > non-standard > > toolchains > > such as Android NDK which only support their custom buildsystem and > > CMake (via > > a > > provided CMake toolchain configuration file). >=20 > Building for Android is trivial using e.g. agcc > https://gist.github.com/angad/1033321 This "agcc" has all flags hard-coded and simply does not work with third-party NDKs such as CrystaX NDK, which is exactly the point I'm trying to make. >=20 > >=20 > > This way, one does not need to extract required compiler flags > > manually. > > Moreover, this simplifies life for projects which use CMake and > > LMDB, because a > > proper CMake buildsystem allows to e. g. automatically pass > > transitive > > dependencies like pthreads to dependent projects. >=20 > Using agcc allows one to build for Android any project that simply > uses Make,=C2=A0 > which was 100% of them before CMake came along. This is false, as shown above. >=20 > Transitive dependencies like pthreads, which you have now embedded > into your=C2=A0 > CMakeLists.txt file, are actually compiler and platform dependent. > That's why=C2=A0 > the LMDB Makefile sets it in an overridable macro, that a programmer > can=C2=A0 > easily change on the commandline when invoking make on their chosen > build=C2=A0 > platform. True; this can be fixed. >=20 > Rejecting this patch and all future patches involving CMake. We will > not use=C2=A0 > this tool ourselves and we will not maintain files that it uses in > the LMDB=C2=A0 > source tree. If you don't like CMake out of personal motives, please just say so and don't cover it with made-up reasons. >=20 > If you need to integrate LMDB into a particular CMake-based project, > it's a=C2=A0 > lot simpler than this. E.g., > https://github.com/LMDB/bitmonero/blob/master/external/db_drivers/lib > lmdb/CMakeLists.txt >=20 > There's no reason to duplicate the entire Makefile when you're > embedding LMDB=C2=A0 > into some other project. This also shows the correct way to use CMake > and=C2=A0 > propagate threads dependencies. >=20 This file does not cover packaging and exporting targets, which is crucial when building multiple dependent projects in a staging tree (e. g. cross-compiling stuff). You see, it is easier to have a single correct build script in the upstream repo than to have many ad-hoc build scripts in each project, each deficient in its own regard. --=20 Ivan Shapovalov / intelfx / --=-Nq65m7sM2GaofoKVHHN0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJXt8N1AAoJEHveF8jk4w6dxNMP/0rbPnFVC6SP7ouTI8XhSdRq YmTl5f3clANv29PV5d6VpEROrbom0Exw07oBFIo4pN01Wo8/Gc48P/2NWZhO+IIZ qvhxTjatCIIZWviZprzQqQK/1VaH4F0IPA7vDHTZGu6G6OHHw70rKIWRh00x0K46 PZfmHZCN5akfdWVniX/Uc7RplAFyOzrnZZRfulfNPPCgwtwoenJ6mO0k4zWwJtP8 Yk/ipwHpXFAkuU5UQ0ObHJfmcCSebFEt53knDfUV7u2aBg24bFTMK0IfX3RuNN1D /fAV0WuoMS6HtTEfaOiUtlemjejxiOxCHFwHbe31Q2XgO3fSOuyv3qrdJCBKwJAX 8/MUbTf2RRA5pdAgiELEZ8o3mMuf0Gjs9BYC+Who5F+cy/3v0ga44MmRZwjtRZre 7h9GeqcgInNtRj9eYOeHPmSdLh8v/6RJRm7OQ/NkeFcKQdooMqd0vsbCWSWkdpyo rb3opd+mv8iRM6rVpEOyQDfWEguVIhemUB6g5/jyjO3tAcjIhwxnImvPTJXjNB9z OmTwnoVezixG8cJ6dYZYr3tSq7okBJd3DjTyxpB5VkWcp12+59vBLfkVrhEzA7Qw fMOPItN/2FymaLsh2kYv3jVLCl3r2hQ+LP2rPD4NWTC5MLcsxRCgJLfTvrALuRp0 IJCyUdAOf+xXzd6VF53n =Ln4x -----END PGP SIGNATURE----- --=-Nq65m7sM2GaofoKVHHN0--

1 0

Re: (ITS#8483) CMake buildsystem support for LMDB
by hyc＠symas.com 19 Aug '16

19 Aug '16

intelfx(a)intelfx.name wrote: > Full_Name: Ivan Shapovalov > Version: LMDB 0.9.18 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ivan-shapovalov-160820.patch > Submission from: (NULL) (77.41.63.43) > > > This patch adds a CMake buildsystem for LMDB, side-by-side with existing > Makefile. > It builds the same targets except coverage tests. I am not a fan of CMake. Using it requires learning a whole new set of documentation in addition to knowing the rules of Make. It comes with a huge footprint of dependencies, and most people using it are misusing it. > Rationale for this change: CMake simplifies building of LMDB with non-standard > toolchains > such as Android NDK which only support their custom buildsystem and CMake (via > a > provided CMake toolchain configuration file). Building for Android is trivial using e.g. agcc https://gist.github.com/angad/1033321 > This way, one does not need to extract required compiler flags manually. > Moreover, this simplifies life for projects which use CMake and LMDB, because a > proper CMake buildsystem allows to e. g. automatically pass transitive > dependencies like pthreads to dependent projects. Using agcc allows one to build for Android any project that simply uses Make, which was 100% of them before CMake came along. Transitive dependencies like pthreads, which you have now embedded into your CMakeLists.txt file, are actually compiler and platform dependent. That's why the LMDB Makefile sets it in an overridable macro, that a programmer can easily change on the commandline when invoking make on their chosen build platform. Rejecting this patch and all future patches involving CMake. We will not use this tool ourselves and we will not maintain files that it uses in the LMDB source tree. If you need to integrate LMDB into a particular CMake-based project, it's a lot simpler than this. E.g., https://github.com/LMDB/bitmonero/blob/master/external/db_drivers/liblmdb/C… There's no reason to duplicate the entire Makefile when you're embedding LMDB into some other project. This also shows the correct way to use CMake and propagate threads dependencies. -- -- 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#8483) CMake buildsystem support for LMDB
by intelfx＠intelfx.name 19 Aug '16

19 Aug '16

Full_Name: Ivan Shapovalov Version: LMDB 0.9.18 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ivan-shapovalov-160820.patch Submission from: (NULL) (77.41.63.43) This patch adds a CMake buildsystem for LMDB, side-by-side with existing Makefile. It builds the same targets except coverage tests. Rationale for this change: CMake simplifies building of LMDB with non-standard toolchains such as Android NDK which only support their custom buildsystem and CMake (via a provided CMake toolchain configuration file). This way, one does not need to extract required compiler flags manually. Moreover, this simplifies life for projects which use CMake and LMDB, because a proper CMake buildsystem allows to e. g. automatically pass transitive dependencies like pthreads to dependent projects.

1 0

(ITS#8482) Assertion failed with back-meta
by hydrazine＠bergzand.net 19 Aug '16

19 Aug '16

Full_Name: Koen Zandberg Version: 2.4.44 OS: Debian Jessie URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.89.160.191) I'm currently deploying an openldap server (version 2.4.44 ltb-project package) with back-meta and with config in the in database format. Slapd crashes with an assertion failed error whenever I modify the suffixmassaging property in the config of one of the backends of my meta backend. What did I do: I created an olcDatabase={2}meta,cn=config with multiple backends. The intial config was converted from a slapd.conf style configfile. Openldap loads the config correct and everything works as expected. I've tried editting one of the rewriterules of the meta URI backends (olcMetaSub={0}uri,olcDatabase={2}meta,cn=config) with ldapvi. specifically the olcDbRewrite: {0}suffixmassage What did I expect: Either an updated rewriterule or an error when committing. What happens: Slapd crashes with an assertion error: slapd: config.c:59: rewrite_parse: Assertion `info != ((void *)0)' failed. Aborted It seems to happen when any rewriterule is modified, not only when modifying the suffixmassage rules If more information is required such as more debug information or specific config options I gladly provide them Regards Koen Zandberg

1 0

Re: (ITS#8481) macOS shared libraries should be .dylib not .so
by hyc＠symas.com 19 Aug '16

19 Aug '16

ilovezfs(a)icloud.com wrote: > Full_Name: ilovezfs > Version: LMDB_0.9.18 > OS: macOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (50.168.32.161) > > > This is in regard to the Homebrew formula for LMDB (See > https://github.com/Homebrew/homebrew-core/pull/2317). Currently, we are having > to patch the shared library extensions from .so to .dylib, which is the correct > file extension on macOS. It would be great if this patch could be removed from > the formula, which would mean upstream support for automatically setting the > extension correctly based on platform in the build system. > > This is a pretty common practice, and it would be highly appreciated as we like > to as little patching as possible to upstream code for maintainability and > fidelity. > > In particular, we're currently having to do the following replacement: > ``` > inreplace "Makefile", ".so", ".dylib" > ``` Fixed in commit c6510147cee88d182af431c14a61fad6fae18be3 > Here's a typical example of how shared libraries get named on macOS: > ``` > libiconv.2.4.0.dylib -> libiconv.2.dylib > libiconv.2.dylib > libiconv.dylib -> libiconv.2.4.0.dylib > ``` > > -- -- 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#8481) macOS shared libraries should be .dylib not .so
by ilovezfs＠icloud.com 19 Aug '16

19 Aug '16

Full_Name: ilovezfs Version: LMDB_0.9.18 OS: macOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.168.32.161) This is in regard to the Homebrew formula for LMDB (See https://github.com/Homebrew/homebrew-core/pull/2317). Currently, we are having to patch the shared library extensions from .so to .dylib, which is the correct file extension on macOS. It would be great if this patch could be removed from the formula, which would mean upstream support for automatically setting the extension correctly based on platform in the build system. This is a pretty common practice, and it would be highly appreciated as we like to as little patching as possible to upstream code for maintainability and fidelity. In particular, we're currently having to do the following replacement: ``` inreplace "Makefile", ".so", ".dylib" ``` Here's a typical example of how shared libraries get named on macOS: ``` libiconv.2.4.0.dylib -> libiconv.2.dylib libiconv.2.dylib libiconv.dylib -> libiconv.2.4.0.dylib ```

1 0

Re: (ITS#8480) running sample-mdb without ./testdb/
by hyc＠symas.com 17 Aug '16

17 Aug '16

gp.ciceri(a)gmail.com wrote: > Full_Name: gian paolo ciceri > Version: lmdb 0.9.18 > OS: OSX > URL: ftp://ftp.openldap/org/incoming > Submission from: (NULL) (5.170.1.95) > > > With lmdb (fresh git clone), if you run the standard sample-mdb.c example > program WITHOUT creating the ./testdb/ directory for the database before, you > take error 2 No such file or directory after the open. OK, but if you still > proceed to the begin the transaction, you take a segmentation fault 11: there's > what gdb says > There is no sample-mdb.c in a fresh git clone. There is a sample-mdb.txt. It is a text file, which you are expected to read, not run blindly. Closing this ITS. -- -- 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#8480) running sample-mdb without ./testdb/
by gp.ciceri＠gmail.com 17 Aug '16

17 Aug '16

Full_Name: gian paolo ciceri Version: lmdb 0.9.18 OS: OSX URL: ftp://ftp.openldap/org/incoming Submission from: (NULL) (5.170.1.95) With lmdb (fresh git clone), if you run the standard sample-mdb.c example program WITHOUT creating the ./testdb/ directory for the database before, you take error 2 No such file or directory after the open. OK, but if you still proceed to the begin the transaction, you take a segmentation fault 11: there's what gdb says sample-mdb Program received signal SIGSEGV, Segmentation fault. 0x0000000100001443 in mdb_txn_renew0 (txn=0x0) at ../mdb.c:2619 2619 MDB_env *env =xtxn->mt_env; Of course there is NO reason to begin the tnx if the open fails, but should not be better to trap this situation and comply instead of proceed and generate the segfault? Perhaps you suppose the program knows what is doing, but I (as programmer) am less sure of myself. Best regards, thanks for your attention. /gp

1 0

(ITS#8479) overlay unique + mdb: loop and OOM kill, 2 URS as olcUniqueURI value
by william.b.clay＠acm.org 15 Aug '16

15 Aug '16

Full_Name: Bill Clay Version: 2.4.44 OS: Debian/GNU Linux 7.8 (Wheezy) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.15.115.130) The below modification to an otherwise correctly-functioning slapd instance provokes an infinite loop that eventually ends with allocation of all configured virtual memory, kernel invocation of its oom-killer (generally on an innocent bystander), and sometimes a kernel panic. This scenario is 100% repeatable on this installation. If I understand "man 5 slapo-unique" correctly, an instance of overlay unique may specify more than one olcUniqueURI attribute, each of which may specify more than one space-separated (?) URI. In this case, I am replacing two initially-configured olcUniqueURI attributes whose values comprise a single URI each (and which seem to work correctly) by one olcUniqueURI attribute with two URIs. bill@fuji:~$ sudo ldapmodify -YEXTERNAL -Hldapi:// SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn:olcOverlay={2}unique,olcDatabase={3}mdb,cn=config changetype: modify replace: olcUniqueURI olcUniqueURI: ldap:///ou=gruppi,dc=test?gidNumber?one ldap:///ou=gruppi,dc=test?owner?one modifying entry "olcOverlay={2}unique,olcDatabase={3}mdb,cn=config" ldap_result: Can't contact LDAP server (-1) bill@fuji:~$ This slapd is the following custom build on an otherwise fairly stock Debian Wheezy system. cd /usr/local/src/openldap-2.4.44 ./configure --sysconfdir=/etc --localstatedir=/ \ --disable-backends --enable-mdb --enable-monitor --enable-crypt \ --with-cyrus-sasl --enable-spasswd --enable-syslog --enable-local \ --disable-overlays --enable-memberof --enable-refint --enable-unique \ --disable-modules --with-cyrus-sasl --with-tls --with-threads --with-gnu-ld # if --enable-shell, avoid --with threads I have uploaded files bill-clay-160815-<type>.txt to ftp://ftp.openldap.org/incoming/ for the following <types>: log: console log of slapd running foreground with -d1 (serial console at 57600 bps, allowing prompt manual termination via kill -KILL) cnf1-cnf3: slapadd specification of (1) the rootDSE, (2) {2}mdb's tree dc=epici,dc=it, and (3) {3}mdb's tree dc=test (subject of the failed ldapmodify). As is probably obvious from these files, I am an LDAP newbie, so there may be a configuration error here that's painfully obvious to the experienced practictioner.

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