openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Fw: Re: (ITS#8959) duplicate symbols
by ruga＠protonmail.com 28 Jan '19

28 Jan '19

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Monday, January 28, 2019 12:10 PM, Rupert Gallagher <ruga(a)protonmail.com= > wrote: > I can replicate your log when using the default tool-chain by Apple. > > The following causes my system to fail with openldap, replicating my orig= inal bug. > The same settings succeed with many other open source projects: openldap = is the only one that fails. > > 1. install the official clang/llvm tool-chain from llvm.org; > 2. set up the shell as follows: > > export CC=3D"/opt/llvm/bin/clang"; # gcc > export CMAKE_C_COMPILER=3D"/opt/llvm/bin/clang"; > export CPP=3D"/opt/llvm/bin/clang -E"; # cpp > export CXX=3D"/opt/llvm/bin/clang++"; # g++ > export CMAKE_CXX_COMPILER=3D"/opt/llvm/bin/clang++"; # g++ > export AR=3D"/opt/llvm/bin/llvm-ar"; # ar > export CMAKE_AR=3D"/opt/llvm/bin/llvm-ar"; # ar > export CMAKE_LINKER=3D"/usr/bin/ld"; # Apple's own > export NM=3D"/opt/llvm/bin/llvm-nm"; # nm > export CMAKE_NM=3D"/opt/llvm/bin/llvm-nm"; # nm > export CMAKE_OBJDUMP=3D"/opt/llvm/bin/llvm-objdump"; > export RANLIB=3D"/opt/llvm/bin/llvm-ranlib"; > export CMAKE_RANLIB=3D"/opt/llvm/bin/llvm-ranlib"; > sdk_p=3D"$( /usr/bin/xcode-select -print-path )"; > sdk_v=3D"$( /usr/bin/xcrun --show-sdk-version )"; > > > runtime compatibility with former versions: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > sdk_c=3D"${sdk_v}"; > case $sdk_v in > 10.14) sdk_c=3D"10.13";; > 10.13) sdk_c=3D"10.13";; > esac > > CFLAGS=3D""; > CCFLAGS=3D""; > CPPFLAGS=3D""; > LDFLAGS=3D""; > > export MACOSX_DEPLOYMENT_TARGET=3D"${sdk_c}"; > CFLAGS=3D"$CFLAGS -g -mmacosx-version-min=3D${sdk_c} -isysroot ${sdk_p}/P= latforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk"; > CFLAGS=3D"$CFLAGS -arch x86_64"; > > exploit mitigation: RELRO + BIND_NOW > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > LDFLAGS=3D"$LDFLAGS -Wl,-z,relro,-z,now"; > > exploit mitigation: stack canary > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > CFLAGS=3D"$CFLAGS -fstack-protector-all"; > > nicer stack traces in error messages > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > CFLAGS=3D"$CFLAGS -fno-omit-frame-pointer"; > > exploit mitigations: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > CFLAGS=3D"$CFLAGS -fPIC -fPIE"; > LDFLAGS=3D"$LDFLAGS -pie"; > > exploit mitigation: protect memory and string functions > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > CFLAGS=3D"$CFLAGS -O2"; > CPPFLAGS=3D"$CPPFLAGS -D_FORTIFY_SOURCE=3D2"; > > exploit mitigation: format string warnings as errors > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > CFLAGS=3D"$CFLAGS -Wformat -Wformat-security -Werror=3Dformat-security"; > > export CFLAGS; > export CCFLAGS=3D"$CFLAGS"; > export CPPFLAGS; > export CXXFLAGS=3D"$CPPFLAGS"; > export LDFLAGS; > export DSOFLAGS=3D"$LDFLAGS";

1 0

Re: (ITS#8959) duplicate symbols
by hyc＠symas.com 25 Jan '19

25 Jan '19

ruga(a)protonmail.com wrote: >> It builds just fine with zero issues. >I'll believe you when I see your log. Ah right, we're all just liars, and that's why it's so important for you to use our software. Quit wasting our time. The burden of proof is on you to provide logs, not us. -- -- 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#8959) duplicate symbols
by ruga＠protonmail.com 25 Jan '19

25 Jan '19

This is a multi-part message in MIME format. --b1_79bd4f6e67d888ad581efca0722453e4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 PiBJdCBidWlsZHMganVzdCBmaW5lIHdpdGggemVybyBpc3N1ZXMuCgpJJ2xsIGJlbGlldmUgeW91 IHdoZW4gSSBzZWUgeW91ciBsb2cuCgpPbiBGcmksIEphbiAyNSwgMjAxOSBhdCAxNjowOSwgUXVh bmFoIEdpYnNvbi1Nb3VudCA8cXVhbmFoQHN5bWFzLmNvbT4gd3JvdGU6Cgo+IC0tT24gRnJpZGF5 LCBKYW51YXJ5IDI1LCAyMDE5IDc6NDIgQU0gKzAwMDAgUnVwZXJ0IEdhbGxhZ2hlcgo+IDxydWdh QHByb3Rvbm1haWwuY29tPiB3cm90ZToKPgo+Pgo+PiBJdCBpcyBldmlkZW50IGZyb20gdGhlIGJ1 ZyByZXBvcnQgdGhhdCB0aGUgbGlua2VyIGlzIHJlYWRpbmcgdHdpY2UgZnJvbQo+PiB0aGUgc2Ft ZSBwYXRoIGluc2lkZSBvcGVubGRhcCdzIHNvdXJjZSBmb2xkZXIuCj4+Cj4+Cj4+IFRoZSBsaW5r ZXIganVzdCBmb2xsb3dzIHlvdXIgaW5zdHJ1Y3Rpb25zLgo+Cj4gQWdhaW4sIHRoZXJlIGlzIGEg cHJvYmxlbSBzcGVjaWZpYyB0byB5b3VyIGJ1aWxkIGVudmlyb25tZW50Lgo+Cj4gSnVzdCBmb3Ig a2lja3MsIEkgZG93bmxvYWRlZCBhbmQgYnVpbHQgT3BlbkxEQVAgMi40LjQ3IHRvZGF5IG9uIG15 IE9TWAo+IGxhcHRvcCAoRGFyd2luIDE4LjIuMCkgd2l0aCB0aGUgY3VycmVudCBYY29kZSByZWxl YXNlLgo+Cj4gSXQgYnVpbGRzIGp1c3QgZmluZSB3aXRoIHplcm8gaXNzdWVzLgo+Cj4gLS1RdWFu YWgKPgo+IC0tCj4KPiBRdWFuYWggR2lic29uLU1vdW50Cj4gUHJvZHVjdCBBcmNoaXRlY3QKPiBT eW1hcyBDb3Jwb3JhdGlvbgo+IFBhY2thZ2VkLCBjZXJ0aWZpZWQsIGFuZCBzdXBwb3J0ZWQgTERB UCBzb2x1dGlvbnMgcG93ZXJlZCBieSBPcGVuTERBUDoKPiA8aHR0cDovL3d3dy5zeW1hcy5jb20+ --b1_79bd4f6e67d888ad581efca0722453e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 ICAgPGRpdj4mZ3Q7Jm5ic3A7PHNwYW4gc3R5bGU9Ii13ZWJraXQtdGV4dC1zaXplLWFkanVzdDog YXV0bzsiPkl0IGJ1aWxkcyBqdXN0IGZpbmUgd2l0aCB6ZXJvIGlzc3Vlcy48L3NwYW4+PC9kaXY+ PGRpdj48c3BhbiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyI+PGJyPjwv c3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1 dG87Ij5JJ2xsIGJlbGlldmUgeW91IHdoZW4gSSBzZWUgeW91ciBsb2cuPC9zcGFuPjwvZGl2PiA8 ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj5PbiBGcmksIEphbiAyNSwgMjAxOSBhdCAxNjow OSwgUXVhbmFoIEdpYnNvbi1Nb3VudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1YW5haEBzeW1hcy5j b20iIGNsYXNzPSIiPnF1YW5haEBzeW1hcy5jb208L2E+Jmd0OyB3cm90ZTo8YmxvY2txdW90ZSBj bGFzcz0icHJvdG9ubWFpbF9xdW90ZSIgdHlwZT0iY2l0ZSI+ICAtLU9uIEZyaWRheSwgSmFudWFy eSAyNSwgMjAxOSA3OjQyIEFNICswMDAwIFJ1cGVydCBHYWxsYWdoZXI8YnI+Jmx0O3J1Z2FAcHJv dG9ubWFpbC5jb20mZ3Q7IHdyb3RlOjxicj48YnI+Jmd0Ozxicj4mZ3Q7IEl0IGlzIGV2aWRlbnQg ZnJvbSB0aGUgYnVnIHJlcG9ydCB0aGF0IHRoZSBsaW5rZXIgaXMgcmVhZGluZyB0d2ljZSBmcm9t PGJyPiZndDsgdGhlIHNhbWUgcGF0aCBpbnNpZGUgb3BlbmxkYXAncyBzb3VyY2UgZm9sZGVyLjxi cj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyBUaGUgbGlua2VyIGp1c3QgZm9sbG93cyB5b3VyIGluc3Ry dWN0aW9ucy48YnI+PGJyPkFnYWluLCB0aGVyZSBpcyBhIHByb2JsZW0gc3BlY2lmaWMgdG8geW91 ciBidWlsZCBlbnZpcm9ubWVudC48YnI+PGJyPkp1c3QgZm9yIGtpY2tzLCBJIGRvd25sb2FkZWQg YW5kIGJ1aWx0IE9wZW5MREFQIDIuNC40NyB0b2RheSBvbiBteSBPU1g8YnI+bGFwdG9wIChEYXJ3 aW4gMTguMi4wKSB3aXRoIHRoZSBjdXJyZW50IFhjb2RlIHJlbGVhc2UuPGJyPjxicj5JdCBidWls ZHMganVzdCBmaW5lIHdpdGggemVybyBpc3N1ZXMuPGJyPjxicj4tLVF1YW5haDxicj48YnI+PGJy Pjxicj4tLTxicj48YnI+UXVhbmFoIEdpYnNvbi1Nb3VudDxicj5Qcm9kdWN0IEFyY2hpdGVjdDxi cj5TeW1hcyBDb3Jwb3JhdGlvbjxicj5QYWNrYWdlZCwgY2VydGlmaWVkLCBhbmQgc3VwcG9ydGVk IExEQVAgc29sdXRpb25zIHBvd2VyZWQgYnkgT3BlbkxEQVA6PGJyPiZsdDtodHRwOi8vd3d3LnN5 bWFzLmNvbSZndDs8YnI+PGJyPjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48 L2Rpdj4= --b1_79bd4f6e67d888ad581efca0722453e4--

1 0

(ITS#8962) Dead links in FAQ page "Where can I find listings of schema items?"
by michael＠stroeder.com 25 Jan '19

25 Jan '19

Full_Name: Michael Str.der Version: OS: URL: Submission from: (NULL) (213.240.182.19) All links herein are dead: https://www.openldap.org/faq/data/cache/220.html I'd suggest to remove this FAQ page completely.

1 0

Re: (ITS#8959) duplicate symbols
by quanah＠symas.com 25 Jan '19

25 Jan '19

--On Friday, January 25, 2019 7:42 AM +0000 Rupert Gallagher <ruga(a)protonmail.com> wrote: > > It is evident from the bug report that the linker is reading twice from > the same path inside openldap's source folder. > > > The linker just follows your instructions. Again, there is a problem specific to your build environment. Just for kicks, I downloaded and built OpenLDAP 2.4.47 today on my OSX laptop (Darwin 18.2.0) with the current Xcode release. It builds just fine with zero issues. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8875) [Patch] Performance problems in back-mdb with large DITs and many aliases
by quanah＠symas.com 25 Jan '19

25 Jan '19

--On Friday, January 25, 2019 1:51 PM +0000 hbohnenkamp(a)united-internet.de wrote: > While writing the test scripts I was wondering if somebody else did > ever do something similar. There are of course tests in the test > directory of the Openldap sources, but are there any (regression) > tests made (e.g. for Openldap release candidates) which try to > simulate large productive setups? Hi Henrik, I've been expanding the regression test cases (See tests/data/regressions) and made it possible to run "make its" to trigger executing them prior to releases. However for obvious reasons that clearly isn't going to include large datasets. I've been quite interested in setting adding tests for large data sets that are stored and executed outside of the regular set of OpenLDAP tests and source tree but so far haven't had a specific case that required such a thing. So if this issue turns out to require testing against a large data set, it could be the first item for that work. Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8875) [Patch] Performance problems in back-mdb with large DITs and many aliases
by hbohnenkamp＠united-internet.de 25 Jan '19

25 Jan '19

Some months have passed but I finally found the time to set up a test rig for regression testing of my patch under LIVE conditions. I'll describe the setup below. The good news is, today I found the first bug in my patch (handling of scope=one searches is incorrect). I say "good" news because it shows that the testing setup is doing something right. In related news, it turns out that apparently the implementation of alias-dereferencing in the hdb backend seems to be faulty, too... not wrt performance, but pureley from a functional point of view. We found a search request which should return around 6700 entries, but only deliveres around 6150. My patched mdb-implementation returns more closely to 6700 entries, but for obvious reasons also that might be wrong still. I had not the time yet to find out what goes wrong in the hdb backend. I'll open a bug if I manage to reproduce it somehow under lab conditions. My test setup is like this: I use the productive LDAP content of my company of about 2.4 million Entries, slapcated from the LDAP master, to test against. All user passwd hashes are replaced with a default hash so that the test tool can bind successfully. Slapd configuration is essentially the same as for our productive slaves (esp. the ACLs). As test cases I use slapd logfiles of our productive clusters (approx 24 million log lines (stats) per server per 24h). Mostly binds and searches. Those are directed against the hdb-configured slapd and a patched-mdb-configured slapd (v 2.4.47). Results are compared: whether binds succeed or fail, and the returned search results. I will extend the tester to also include other operations, but this is waht is relevant to test the patch, I guess. In the taxonomy of test-methods I would classify this as "advanced monkey testing". While writing the test scripts I was wondering if somebody else did ever do something similar. There are of course tests in the test directory of the Openldap sources, but are there any (regression) tests made (e.g. for Openldap release candidates) which try to simulate large productive setups? -- Henrik Bohnenkamp

1 0

Re: (ITS#8959) duplicate symbols
by ruga＠protonmail.com 25 Jan '19

25 Jan '19

This is a multi-part message in MIME format. --b1_4735ab60e16b531e1cbee2b5bac08b8c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SXQgaXMgZXZpZGVudCBmcm9tIHRoZSBidWcgcmVwb3J0IHRoYXQgdGhlIGxpbmtlciBpcyByZWFk aW5nIHR3aWNlIGZyb20gdGhlIHNhbWUgcGF0aCBpbnNpZGUgb3BlbmxkYXAncyBzb3VyY2UgZm9s ZGVyLgoKVGhlIGxpbmtlciBqdXN0IGZvbGxvd3MgeW91ciBpbnN0cnVjdGlvbnMuCgpPbiBGcmks IEphbiAyNSwgMjAxOSBhdCAwMTozMSwgUXVhbmFoIEdpYnNvbi1Nb3VudCA8cXVhbmFoQHN5bWFz LmNvbT4gd3JvdGU6Cgo+IC0tT24gVGh1cnNkYXksIEphbnVhcnkgMjQsIDIwMTkgMTA6NTkgUE0g KzAwMDAgcnVnYUBwcm90b25tYWlsLmNvbSB3cm90ZToKPgo+PiBUaGlzIGlzIGEgbXVsdGktcGFy dCBtZXNzYWdlIGluIE1JTUUgZm9ybWF0Lgo+Pgo+PiAtLWIxXzI2NjVhMzUzNjdiOWYyOWQyOWU0 YjBlZmMwNWM3OTgxCj4+IENvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD1VVEYtOAo+ PiBDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBiYXNlNjQKPj4KPj4gTXkgYnVpbGQgZW52aXJv bm1lbnQgd29ya3Mgd2VsbCBmb3IgbWFueSBvcGVuIHNvdXJjZSBwcm9qZWN0cy4KPgo+IE9wZW5M REFQIGJ1aWxkcyBhY3Jvc3MgZG96ZW5zIG9mIGxpbnV4IGRpc3RyaWJ1dGlvbnMgYW5kIG9wZXJh dGluZyBzeXN0ZW1zCj4ganVzdCBmaW5lLiBUaGUgZXJyb3IgeW91J3ZlIHByb3ZpZGVkIGNsZWFy bHkgaW5kaWNhdGVzIHRoZXJlJ3MgYSBwcm9ibGVtCj4gd2l0aCB0aGUgc2V0dXAgb24geW91ciBz eXN0ZW0gYW5kIGRvZXMgbm90IHNob3cgYW55IGluZGljYXRpb24gb2YgYSBwcm9ibGVtCj4gd2l0 aCB0aGUgT3BlbkxEQVAgYnVpbGQgcHJvY2Vzcy4gQXMgd2FzIGFscmVhZHkgbm90ZWQsIHRoZXJl IGFyZSBubwo+IGR1cGxpY2F0ZSBzeW1ib2xzIGluIHRoZSBPcGVuTERBUCBzb3VyY2UgY29kZS4g SSB3b3VsZCBndWVzcyB0aGF0IHlvdQo+IHBlcmhhcHMgaGF2ZSBhbm90aGVyIGluc3RhbGxhdGlv biBvZiBPcGVuTERBUCdzIGxpYmxiZXIgdGhhdCdzIGdldHRpbmcKPiBpbmNvcnJlY3RseSBpbmNs dWRlZCBkdXJpbmcgdGhlIGxpbmsgcGhhc2UuIFJlZ2FyZGxlc3MsIHRoZSBPcGVuTERBUCBJVFMK PiBzeXN0ZW0gaXMgZm9yIHJlcG9ydGluZyBidWdzIGluIHRoZSBPcGVuTERBUCBzb2Z0d2FyZS4g SXQgaXMgbm90IGZvcgo+IHJlcG9ydGluZyBpc3N1ZXMgd2l0aCB5b3VyIGJ1aWxkIGVudmlyb25t ZW50LiBUaGlzIElUUyB3aWxsIHJlbWFpbiBjbG9zZWQuCj4KPiBJZiB5b3UgbmVlZCBhZGRpdGlv bmFsIGFzc2lzdGFuY2Ugd2l0aCBjb21waWxpbmcgT3BlbkxEQVAsIHlvdSBtYXkgd2lzaCB0bwo+ IGFzayBvbiB0aGUgb3BlbmxkYXAtdGVjaG5pY2FsQG9wZW5sZGFwLm9yZyBtYWlsaW5nIGxpc3Qu IEhvd2V2ZXIgSSB3b3VsZAo+IGZpcnN0IHJlc29sdmUgd2hhdGV2ZXIncyBicm9rZW4gaW4geW91 ciBidWlsZCBlbnZpcm9ubWVudCBhcyBpdCdzIGNsZWFybHkKPiBub3QgYW4gT3BlbkxEQVAgaXNz dWUuCj4KPiBXYXJtIHJlZ2FyZHMsCj4gUXVhbmFoCj4KPiAtLQo+Cj4gUXVhbmFoIEdpYnNvbi1N b3VudAo+IFByb2R1Y3QgQXJjaGl0ZWN0Cj4gU3ltYXMgQ29ycG9yYXRpb24KPiBQYWNrYWdlZCwg Y2VydGlmaWVkLCBhbmQgc3VwcG9ydGVkIExEQVAgc29sdXRpb25zIHBvd2VyZWQgYnkgT3BlbkxE QVA6Cj4gPGh0dHA6Ly93d3cuc3ltYXMuY29tPg== --b1_4735ab60e16b531e1cbee2b5bac08b8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdj5JdCBpcyBldmlkZW50IGZyb20gdGhlIGJ1ZyByZXBvcnQgdGhhdCB0aGUgbGlua2VyIGlz IHJlYWRpbmcgdHdpY2UgZnJvbSB0aGUgc2FtZSBwYXRoIGluc2lkZSBvcGVubGRhcCdzIHNvdXJj ZSBmb2xkZXIuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUgbGlua2VyIGp1c3QgZm9sbG93 cyB5b3VyIGluc3RydWN0aW9ucy4mbmJzcDs8L2Rpdj4gPGRpdj48YnI+PC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj48YnI+PC9kaXY+T24gRnJpLCBKYW4gMjUsIDIwMTkgYXQgMDE6MzEsIFF1YW5h aCBHaWJzb24tTW91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWFuYWhAc3ltYXMuY29tIiBjbGFz cz0iIj5xdWFuYWhAc3ltYXMuY29tPC9hPiZndDsgd3JvdGU6PGJsb2NrcXVvdGUgY2xhc3M9InBy b3Rvbm1haWxfcXVvdGUiIHR5cGU9ImNpdGUiPiAgLS1PbiBUaHVyc2RheSwgSmFudWFyeSAyNCwg MjAxOSAxMDo1OSBQTSArMDAwMCBydWdhQHByb3Rvbm1haWwuY29tIHdyb3RlOjxicj48YnI+Jmd0 OyBUaGlzIGlzIGEgbXVsdGktcGFydCBtZXNzYWdlIGluIE1JTUUgZm9ybWF0Ljxicj4mZ3Q7PGJy PiZndDsgLS1iMV8yNjY1YTM1MzY3YjlmMjlkMjllNGIwZWZjMDVjNzk4MTxicj4mZ3Q7IENvbnRl bnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD1VVEYtODxicj4mZ3Q7IENvbnRlbnQtVHJhbnNm ZXItRW5jb2Rpbmc6IGJhc2U2NDxicj4mZ3Q7PGJyPiZndDsgTXkgYnVpbGQgZW52aXJvbm1lbnQg d29ya3Mgd2VsbCBmb3IgbWFueSBvcGVuIHNvdXJjZSBwcm9qZWN0cy48YnI+PGJyPk9wZW5MREFQ IGJ1aWxkcyBhY3Jvc3MgZG96ZW5zIG9mIGxpbnV4IGRpc3RyaWJ1dGlvbnMgYW5kIG9wZXJhdGlu ZyBzeXN0ZW1zPGJyPmp1c3QgZmluZS4gIFRoZSBlcnJvciB5b3UndmUgcHJvdmlkZWQgY2xlYXJs eSBpbmRpY2F0ZXMgdGhlcmUncyBhIHByb2JsZW08YnI+d2l0aCB0aGUgc2V0dXAgb24geW91ciBz eXN0ZW0gYW5kIGRvZXMgbm90IHNob3cgYW55IGluZGljYXRpb24gb2YgYSBwcm9ibGVtPGJyPndp dGggdGhlIE9wZW5MREFQIGJ1aWxkIHByb2Nlc3MuICBBcyB3YXMgYWxyZWFkeSBub3RlZCwgdGhl cmUgYXJlIG5vPGJyPmR1cGxpY2F0ZSBzeW1ib2xzIGluIHRoZSBPcGVuTERBUCBzb3VyY2UgY29k ZS4gIEkgd291bGQgZ3Vlc3MgdGhhdCB5b3U8YnI+cGVyaGFwcyBoYXZlIGFub3RoZXIgaW5zdGFs bGF0aW9uIG9mIE9wZW5MREFQJ3MgbGlibGJlciB0aGF0J3MgZ2V0dGluZzxicj5pbmNvcnJlY3Rs eSBpbmNsdWRlZCBkdXJpbmcgdGhlIGxpbmsgcGhhc2UuICBSZWdhcmRsZXNzLCB0aGUgT3BlbkxE QVAgSVRTPGJyPnN5c3RlbSBpcyBmb3IgcmVwb3J0aW5nIGJ1Z3MgaW4gdGhlIE9wZW5MREFQIHNv ZnR3YXJlLiAgSXQgaXMgbm90IGZvcjxicj5yZXBvcnRpbmcgaXNzdWVzIHdpdGggeW91ciBidWls ZCBlbnZpcm9ubWVudC4gIFRoaXMgSVRTIHdpbGwgcmVtYWluIGNsb3NlZC48YnI+PGJyPklmIHlv dSBuZWVkIGFkZGl0aW9uYWwgYXNzaXN0YW5jZSB3aXRoIGNvbXBpbGluZyBPcGVuTERBUCwgeW91 IG1heSB3aXNoIHRvPGJyPmFzayBvbiB0aGUgb3BlbmxkYXAtdGVjaG5pY2FsQG9wZW5sZGFwLm9y ZyBtYWlsaW5nIGxpc3QuICBIb3dldmVyIEkgd291bGQ8YnI+Zmlyc3QgcmVzb2x2ZSB3aGF0ZXZl cidzIGJyb2tlbiBpbiB5b3VyIGJ1aWxkIGVudmlyb25tZW50IGFzIGl0J3MgY2xlYXJseTxicj5u b3QgYW4gT3BlbkxEQVAgaXNzdWUuPGJyPjxicj5XYXJtIHJlZ2FyZHMsPGJyPlF1YW5haDxicj48 YnI+PGJyPi0tPGJyPjxicj5RdWFuYWggR2lic29uLU1vdW50PGJyPlByb2R1Y3QgQXJjaGl0ZWN0 PGJyPlN5bWFzIENvcnBvcmF0aW9uPGJyPlBhY2thZ2VkLCBjZXJ0aWZpZWQsIGFuZCBzdXBwb3J0 ZWQgTERBUCBzb2x1dGlvbnMgcG93ZXJlZCBieSBPcGVuTERBUDo8YnI+Jmx0O2h0dHA6Ly93d3cu c3ltYXMuY29tJmd0Ozxicj48YnI+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJy PjwvZGl2Pg== --b1_4735ab60e16b531e1cbee2b5bac08b8c--

1 0

Re: (ITS#8961) Crash when deleting olcDbIndex (back-mdb)
by h.b.furuseth＠usit.uio.no 25 Jan '19

25 Jan '19

On 1/25/19 1:31 AM, ryan(a)nardis.ca wrote: > Possible duplicate of ITS#8472? Yes

1 0

Re: (ITS#8959) duplicate symbols
by quanah＠symas.com 25 Jan '19

25 Jan '19

--On Thursday, January 24, 2019 10:59 PM +0000 ruga(a)protonmail.com wrote: > This is a multi-part message in MIME format. > > --b1_2665a35367b9f29d29e4b0efc05c7981 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: base64 > > My build environment works well for many open source projects. OpenLDAP builds across dozens of linux distributions and operating systems just fine. The error you've provided clearly indicates there's a problem with the setup on your system and does not show any indication of a problem with the OpenLDAP build process. As was already noted, there are no duplicate symbols in the OpenLDAP source code. I would guess that you perhaps have another installation of OpenLDAP's liblber that's getting incorrectly included during the link phase. Regardless, the OpenLDAP ITS system is for reporting bugs in the OpenLDAP software. It is not for reporting issues with your build environment. This ITS will remain closed. If you need additional assistance with compiling OpenLDAP, you may wish to ask on the openldap-technical(a)openldap.org mailing list. However I would first resolve whatever's broken in your build environment as it's clearly not an OpenLDAP issue. Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

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