openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

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

31 Jan '19

--On Thursday, January 31, 2019 8:13 AM +0000 hyc(a)symas.com wrote: > Still, nothing in the OpenLDAP build setup does this. You did it yourself, > most likely the same way you set "-D_FORTIFY_SOURCE=2" 3 times in your > CPPFLAGS. That was actually me when I inaverdently exported the variable more than once when playing with the flags. ;) Just to note. --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#8959) duplicate symbols
by ruga＠protonmail.com 31 Jan '19

31 Jan '19

This is a multi-part message in MIME format. --b1_ce770359f41de57b3c63a57268b4224b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 WW91IGFkZGVkIGl0IHRocmVlIHRpbWVzLCBieSBoYW5kLCBhcyBldmlkZW50IGluIHlvdXIgZm9s bG93dXAgMTIuCgpZb3Ugc2hvdWxkIGZpeCB5b3VyIE1ha2VmaWxlIGluc3RlYWQgb2YgYmxhbWlu ZyBsbHZtIG9yIG15IHBlcmZlY3RseSBmaW5lIHNldHRpbmcuCgpPbiBUaHUsIEphbiAzMSwgMjAx OSBhdCAwOToxMywgSG93YXJkIENodSA8aHljQHN5bWFzLmNvbT4gd3JvdGU6Cgo+IHJ1Z2FAcHJv dG9ubWFpbC5jb20gd3JvdGU6Cj4+IFRoaXMgaXMgYSBtdWx0aS1wYXJ0IG1lc3NhZ2UgaW4gTUlN RSBmb3JtYXQuCj4KPiBQbGVhc2Ugc3RvcCB1c2luZyBIVE1MIGVtYWlsLgo+Pgo+PiAtLWIxX2Q4 NjM3ZGJiMTIwYTUyOWY0ZjI2ZDQzZDRiMDg5Y2VlCj4+IENvbnRlbnQtVHlwZTogdGV4dC9wbGFp bjsgY2hhcnNldD1VVEYtOAo+PiBDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBiYXNlNjQKPj4K Pj4gU1dZZ1NTQmhaR1FnZEdobElDSXRkaUlnYjNCMGFXOXVJSFJ2SUdOc1lXNW5JR2x1SUM0dmJH bGljbUZ5YVdWekwwMWhhMlZtYVd4bAo+Cj4+IElmIEkgYWRkIHRoZSAiLXYiIG9wdGlvbiB0byBj bGFuZyBpbiAuL2xpYnJhcmllcy9NYWtlZmlsZSwgdGhlIHJlc3VsdGluZyBsb2cgc2hvd3MgdGhh dCB0aGUgbGlicmFyeSB3YXMgbGlua2VkIHR3aWNlLCBjYXVzaW5nIHN5bWJvbCBkdXBsaWNhdGlv bi4+Cj4+IFRoaXMgaG9sZHMgb24gbWFjb3MgMTAuMTMgd2l0aCBBcHBsZSB0b29sa2l0IDEwLjE0 IGFuZCB0aGUgb3JpZ2luYWwgbGx2bSA3LjAuMCB3aXRoIHRoZSBnaXZlbiBzZXR0aW5ncy4KPgo+ IFN0aWxsLCBub3RoaW5nIGluIHRoZSBPcGVuTERBUCBidWlsZCBzZXR1cCBkb2VzIHRoaXMuIFlv dSBkaWQgaXQgeW91cnNlbGYsCj4gbW9zdCBsaWtlbHkgdGhlIHNhbWUgd2F5IHlvdSBzZXQgIi1E X0ZPUlRJRllfU09VUkNFPTIiIDMgdGltZXMgaW4geW91ciBDUFBGTEFHUy4KPgo+IFRoaXMgSVRT IGlzIGNsb3NlZC4gVGhlcmUgaXMgbm8gT3BlbkxEQVAgU29mdHdhcmUgaXNzdWUgaGVyZSwgeW91 J3ZlIG1pc2NvbmZpZ3VyZWQKPiB5b3VyIGJ1aWxkLgo+Pgo+PiBPbiBNb24sIEphbiAyOCwgMjAx OSBhdCAxNzoxMSwgUXVhbmFoIEdpYnNvbi1Nb3VudCA8cXVhbmFoQHN5bWFzLmNvbT4gd3JvdGU6 Cj4+Cj4+PiAtLU9uIE1vbmRheSwgSmFudWFyeSAyOCwgMjAxOSAzOjM1IFBNICswMDAwIFJ1cGVy dCBHYWxsYWdoZXIKPj4+IDxydWdhQHByb3Rvbm1haWwuY29tPiB3cm90ZToKPj4+Cj4+Pj4gQXMg eW91IGNhbiBzZWUsIEkgYW0gdXNpbmcgdGhlIGRlZmF1bHQgQXBwbGUgbGlua2VyLCBhbmQgaGFy ZGVuZWQKPj4+PiBzZXR0aW5ncyBmb3IgdGhlIGNvbXBpbGVyLiBUcnkgdXNpbmcgdGhvc2Ugc2V0 dGluZ3MgeW91cnNlbGYsIGFuZCBzZWUKPj4+PiB3aGF0IGNvbWVzIG91dC4KPj4+Cj4+PiBJIHRl c3RlZCBvbiBGcmVlQlNEMTIgKHNpbmNlIGl0IHVzZXMgY2xhbmcgcmF0aGVyIHRoYW4gZ2NjKSB3 aXRoIHRoZQo+Pj4gZm9sbG93aW5nIGZsYWdzIGFuZCB0aGUgYnVpbGQgY29tcGxldGVkIHcvbyBp c3N1ZToKPj4+Cj4+PiBDRkxBR1M9IC1nIC1mc3RhY2stcHJvdGVjdG9yLWFsbCAtZm5vLW9taXQt ZnJhbWUtcG9pbnRlciAtZlBJQyAtZlBJRSAtTzIKPj4+IC1XZm9ybWF0IC1XZm9ybWF0LXNlY3Vy aXR5IC1XZXJyb3I9Zm9ybWF0LXNlY3VyaXR5Cj4+PiBMREZMQUdTPSAtV2wsLXoscmVscm8sLXos bm93IC1waWUKPj4+IENQUEZMQUdTPSAtRF9GT1JUSUZZX1NPVVJDRT0yIC1EX0ZPUlRJRllfU09V UkNFPTIgLURfRk9SVElGWV9TT1VSQ0U9Mgo+Cj4gLS0KPiAtLSBIb3dhcmQgQ2h1Cj4gQ1RPLCBT eW1hcyBDb3JwLiBodHRwOi8vd3d3LnN5bWFzLmNvbQo+IERpcmVjdG9yLCBIaWdobGFuZCBTdW4g aHR0cDovL2hpZ2hsYW5kc3VuLmNvbS9oeWMvCj4gQ2hpZWYgQXJjaGl0ZWN0LCBPcGVuTERBUCBo dHRwOi8vd3d3Lm9wZW5sZGFwLm9yZy9wcm9qZWN0Lw== --b1_ce770359f41de57b3c63a57268b4224b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 ICAgPGRpdj5Zb3UgYWRkZWQgaXQgdGhyZWUgdGltZXMsIGJ5IGhhbmQsIGFzIGV2aWRlbnQgaW4g eW91ciBmb2xsb3d1cCAxMi48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PllvdSBzaG91bGQgZml4 IHlvdXIgTWFrZWZpbGUgaW5zdGVhZCBvZiBibGFtaW5nIGxsdm0gb3IgbXkgcGVyZmVjdGx5IGZp bmUgc2V0dGluZy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48 L2Rpdj5PbiBUaHUsIEphbiAzMSwgMjAxOSBhdCAwOToxMywgSG93YXJkIENodSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmh5Y0BzeW1hcy5jb20iIGNsYXNzPSIiPmh5Y0BzeW1hcy5jb208L2E+Jmd0OyB3 cm90ZTo8YmxvY2txdW90ZSBjbGFzcz0icHJvdG9ubWFpbF9xdW90ZSIgdHlwZT0iY2l0ZSI+ICBy dWdhQHByb3Rvbm1haWwuY29tIHdyb3RlOjxicj4mZ3Q7IFRoaXMgaXMgYSBtdWx0aS1wYXJ0IG1l c3NhZ2UgaW4gTUlNRSBmb3JtYXQuPGJyPjxicj5QbGVhc2Ugc3RvcCB1c2luZyBIVE1MIGVtYWls Ljxicj4mZ3Q7PGJyPiZndDsgLS1iMV9kODYzN2RiYjEyMGE1MjlmNGYyNmQ0M2Q0YjA4OWNlZTxi cj4mZ3Q7IENvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD1VVEYtODxicj4mZ3Q7IENv bnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IGJhc2U2NDxicj4mZ3Q7PGJyPiZndDsgU1dZZ1NTQmha R1FnZEdobElDSXRkaUlnYjNCMGFXOXVJSFJ2SUdOc1lXNW5JR2x1SUM0dmJHbGljbUZ5YVdWekww MWhhMlZtYVd4bDxicj48YnI+Jmd0OyBJZiBJIGFkZCB0aGUgIi12IiBvcHRpb24gdG8gY2xhbmcg aW4gLi9saWJyYXJpZXMvTWFrZWZpbGUsIHRoZSByZXN1bHRpbmcgbG9nIHNob3dzIHRoYXQgdGhl IGxpYnJhcnkgd2FzIGxpbmtlZCB0d2ljZSwgY2F1c2luZyBzeW1ib2wgZHVwbGljYXRpb24uJmd0 Ozxicj4mZ3Q7IFRoaXMgaG9sZHMgb24gbWFjb3MgMTAuMTMgd2l0aCBBcHBsZSB0b29sa2l0IDEw LjE0IGFuZCB0aGUgb3JpZ2luYWwgbGx2bSA3LjAuMCB3aXRoIHRoZSBnaXZlbiBzZXR0aW5ncy48 YnI+PGJyPlN0aWxsLCBub3RoaW5nIGluIHRoZSBPcGVuTERBUCBidWlsZCBzZXR1cCBkb2VzIHRo aXMuIFlvdSBkaWQgaXQgeW91cnNlbGYsPGJyPm1vc3QgbGlrZWx5IHRoZSBzYW1lIHdheSB5b3Ug c2V0ICItRF9GT1JUSUZZX1NPVVJDRT0yIiAzIHRpbWVzIGluIHlvdXIgQ1BQRkxBR1MuPGJyPjxi cj5UaGlzIElUUyBpcyBjbG9zZWQuIFRoZXJlIGlzIG5vIE9wZW5MREFQIFNvZnR3YXJlIGlzc3Vl IGhlcmUsIHlvdSd2ZSBtaXNjb25maWd1cmVkPGJyPnlvdXIgYnVpbGQuPGJyPiZndDs8YnI+Jmd0 OyBPbiBNb24sIEphbiAyOCwgMjAxOSBhdCAxNzoxMSwgUXVhbmFoIEdpYnNvbi1Nb3VudCAmbHQ7 cXVhbmFoQHN5bWFzLmNvbSZndDsgd3JvdGU6PGJyPiZndDs8YnI+Jmd0OyZndDsgLS1PbiBNb25k YXksIEphbnVhcnkgMjgsIDIwMTkgMzozNSBQTSArMDAwMCBSdXBlcnQgR2FsbGFnaGVyPGJyPiZn dDsmZ3Q7ICZsdDtydWdhQHByb3Rvbm1haWwuY29tJmd0OyB3cm90ZTo8YnI+Jmd0OyZndDs8YnI+ Jmd0OyZndDsmZ3Q7IEFzIHlvdSBjYW4gc2VlLCBJIGFtIHVzaW5nIHRoZSBkZWZhdWx0IEFwcGxl IGxpbmtlciwgYW5kIGhhcmRlbmVkPGJyPiZndDsmZ3Q7Jmd0OyBzZXR0aW5ncyBmb3IgdGhlIGNv bXBpbGVyLiBUcnkgdXNpbmcgdGhvc2Ugc2V0dGluZ3MgeW91cnNlbGYsIGFuZCBzZWU8YnI+Jmd0 OyZndDsmZ3Q7IHdoYXQgY29tZXMgb3V0Ljxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBJIHRlc3Rl ZCBvbiBGcmVlQlNEMTIgKHNpbmNlIGl0IHVzZXMgY2xhbmcgcmF0aGVyIHRoYW4gZ2NjKSB3aXRo IHRoZTxicj4mZ3Q7Jmd0OyBmb2xsb3dpbmcgZmxhZ3MgYW5kIHRoZSBidWlsZCBjb21wbGV0ZWQg dy9vIGlzc3VlOjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBDRkxBR1M9IC1nIC1mc3RhY2stcHJv dGVjdG9yLWFsbCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtZlBJQyAtZlBJRSAtTzI8YnI+Jmd0 OyZndDsgLVdmb3JtYXQgLVdmb3JtYXQtc2VjdXJpdHkgLVdlcnJvcj1mb3JtYXQtc2VjdXJpdHk8 YnI+Jmd0OyZndDsgTERGTEFHUz0gLVdsLC16LHJlbHJvLC16LG5vdyAtcGllPGJyPiZndDsmZ3Q7 IENQUEZMQUdTPSAtRF9GT1JUSUZZX1NPVVJDRT0yIC1EX0ZPUlRJRllfU09VUkNFPTIgLURfRk9S VElGWV9TT1VSQ0U9Mjxicj48YnI+PGJyPi0tPGJyPiAgLS0gSG93YXJkIENodTxicj4gIENUTywg U3ltYXMgQ29ycC4gICAgICAgICAgIGh0dHA6Ly93d3cuc3ltYXMuY29tPGJyPiAgRGlyZWN0b3Is IEhpZ2hsYW5kIFN1biAgICAgaHR0cDovL2hpZ2hsYW5kc3VuLmNvbS9oeWMvPGJyPiAgQ2hpZWYg QXJjaGl0ZWN0LCBPcGVuTERBUCAgaHR0cDovL3d3dy5vcGVubGRhcC5vcmcvcHJvamVjdC88YnI+ PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2Pg== --b1_ce770359f41de57b3c63a57268b4224b--

1 0

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

31 Jan '19

ruga(a)protonmail.com wrote: > This is a multi-part message in MIME format. Please stop using HTML email. > > --b1_d8637dbb120a529f4f26d43d4b089cee > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: base64 > > SWYgSSBhZGQgdGhlICItdiIgb3B0aW9uIHRvIGNsYW5nIGluIC4vbGlicmFyaWVzL01ha2VmaWxl > If I add the "-v" option to clang in ./libraries/Makefile, the resulting log shows that the library was linked twice, causing symbol duplication.> > This holds on macos 10.13 with Apple toolkit 10.14 and the original llvm 7.0.0 with the given settings. Still, nothing in the OpenLDAP build setup does this. You did it yourself, most likely the same way you set "-D_FORTIFY_SOURCE=2" 3 times in your CPPFLAGS. This ITS is closed. There is no OpenLDAP Software issue here, you've misconfigured your build. > > On Mon, Jan 28, 2019 at 17:11, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > >> --On Monday, January 28, 2019 3:35 PM +0000 Rupert Gallagher >> <ruga(a)protonmail.com> wrote: >> >>> As you can see, I am using the default Apple linker, and hardened >>> settings for the compiler. Try using those settings yourself, and see >>> what comes out. >> >> I tested on FreeBSD12 (since it uses clang rather than gcc) with the >> following flags and the build completed w/o issue: >> >> CFLAGS= -g -fstack-protector-all -fno-omit-frame-pointer -fPIC -fPIE -O2 >> -Wformat -Wformat-security -Werror=format-security >> LDFLAGS= -Wl,-z,relro,-z,now -pie >> CPPFLAGS= -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 -- -- 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 31 Jan '19

31 Jan '19

This is a multi-part message in MIME format. --b1_d8637dbb120a529f4f26d43d4b089cee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SWYgSSBhZGQgdGhlICItdiIgb3B0aW9uIHRvIGNsYW5nIGluIC4vbGlicmFyaWVzL01ha2VmaWxl LCB0aGUgcmVzdWx0aW5nIGxvZyBzaG93cyB0aGF0IHRoZSBsaWJyYXJ5IHdhcyBsaW5rZWQgdHdp Y2UsIGNhdXNpbmcgc3ltYm9sIGR1cGxpY2F0aW9uLgoKVGhpcyBob2xkcyBvbiBtYWNvcyAxMC4x MyB3aXRoIEFwcGxlIHRvb2xraXQgMTAuMTQgYW5kIHRoZSBvcmlnaW5hbCBsbHZtIDcuMC4wIHdp dGggdGhlIGdpdmVuIHNldHRpbmdzLgoKT24gTW9uLCBKYW4gMjgsIDIwMTkgYXQgMTc6MTEsIFF1 YW5haCBHaWJzb24tTW91bnQgPHF1YW5haEBzeW1hcy5jb20+IHdyb3RlOgoKPiAtLU9uIE1vbmRh eSwgSmFudWFyeSAyOCwgMjAxOSAzOjM1IFBNICswMDAwIFJ1cGVydCBHYWxsYWdoZXIKPiA8cnVn YUBwcm90b25tYWlsLmNvbT4gd3JvdGU6Cj4KPj4gQXMgeW91IGNhbiBzZWUsIEkgYW0gdXNpbmcg dGhlIGRlZmF1bHQgQXBwbGUgbGlua2VyLCBhbmQgaGFyZGVuZWQKPj4gc2V0dGluZ3MgZm9yIHRo ZSBjb21waWxlci4gVHJ5IHVzaW5nIHRob3NlIHNldHRpbmdzIHlvdXJzZWxmLCBhbmQgc2VlCj4+ IHdoYXQgY29tZXMgb3V0Lgo+Cj4gSSB0ZXN0ZWQgb24gRnJlZUJTRDEyIChzaW5jZSBpdCB1c2Vz IGNsYW5nIHJhdGhlciB0aGFuIGdjYykgd2l0aCB0aGUKPiBmb2xsb3dpbmcgZmxhZ3MgYW5kIHRo ZSBidWlsZCBjb21wbGV0ZWQgdy9vIGlzc3VlOgo+Cj4gQ0ZMQUdTPSAtZyAtZnN0YWNrLXByb3Rl Y3Rvci1hbGwgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLWZQSUMgLWZQSUUgLU8yCj4gLVdmb3Jt YXQgLVdmb3JtYXQtc2VjdXJpdHkgLVdlcnJvcj1mb3JtYXQtc2VjdXJpdHkKPiBMREZMQUdTPSAt V2wsLXoscmVscm8sLXosbm93IC1waWUKPiBDUFBGTEFHUz0gLURfRk9SVElGWV9TT1VSQ0U9MiAt RF9GT1JUSUZZX1NPVVJDRT0yIC1EX0ZPUlRJRllfU09VUkNFPTIKPgo+IEluIGFueSBjYXNlLCBJ IHRoaW5rIHdlJ3ZlIHdlbGwgZXN0YWJsaXNoZWQgdGhlIHByb2JsZW0geW91J3JlIGhpdHRpbmcg aGFzCj4gemVybyB0byBkbyB3aXRoIE9wZW5MREFQIGluIGFuZCBvZiBpdHNlbGYuIFlvdSdsbCBu ZWVkIHRvIHRha2UgdGhpcyB1cAo+IGVsc2V3aGVyZS4KPgo+IC0tUXVhbmFoCj4KPiAtLQo+Cj4g UXVhbmFoIEdpYnNvbi1Nb3VudAo+IFByb2R1Y3QgQXJjaGl0ZWN0Cj4gU3ltYXMgQ29ycG9yYXRp b24KPiBQYWNrYWdlZCwgY2VydGlmaWVkLCBhbmQgc3VwcG9ydGVkIExEQVAgc29sdXRpb25zIHBv d2VyZWQgYnkgT3BlbkxEQVA6Cj4gPGh0dHA6Ly93d3cuc3ltYXMuY29tPg== --b1_d8637dbb120a529f4f26d43d4b089cee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 ICAgPGRpdj5JZiBJIGFkZCB0aGUgIi12IiBvcHRpb24gdG8gY2xhbmcgaW4gLi9saWJyYXJpZXMv TWFrZWZpbGUsIHRoZSByZXN1bHRpbmcgbG9nIHNob3dzIHRoYXQgdGhlIGxpYnJhcnkgd2FzIGxp bmtlZCB0d2ljZSwgY2F1c2luZyBzeW1ib2wgZHVwbGljYXRpb24uJm5ic3A7PC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdj5UaGlzIGhvbGRzIG9uIG1hY29zIDEwLjEzIHdpdGggQXBwbGUgdG9vbGtp dCAxMC4xNCBhbmQgdGhlIG9yaWdpbmFsIGxsdm0gNy4wLjAgd2l0aCB0aGUgZ2l2ZW4gc2V0dGlu Z3MuJm5ic3A7PC9kaXY+IDxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2Pk9uIE1vbiwgSmFu IDI4LCAyMDE5IGF0IDE3OjExLCBRdWFuYWggR2lic29uLU1vdW50ICZsdDs8YSBocmVmPSJtYWls dG86cXVhbmFoQHN5bWFzLmNvbSIgY2xhc3M9IiI+cXVhbmFoQHN5bWFzLmNvbTwvYT4mZ3Q7IHdy b3RlOjxibG9ja3F1b3RlIGNsYXNzPSJwcm90b25tYWlsX3F1b3RlIiB0eXBlPSJjaXRlIj4gIC0t T24gTW9uZGF5LCBKYW51YXJ5IDI4LCAyMDE5IDM6MzUgUE0gKzAwMDAgUnVwZXJ0IEdhbGxhZ2hl cjxicj4mbHQ7cnVnYUBwcm90b25tYWlsLmNvbSZndDsgd3JvdGU6PGJyPjxicj4mZ3Q7IEFzIHlv dSBjYW4gc2VlLCBJIGFtIHVzaW5nIHRoZSBkZWZhdWx0IEFwcGxlIGxpbmtlciwgYW5kIGhhcmRl bmVkPGJyPiZndDsgc2V0dGluZ3MgZm9yIHRoZSBjb21waWxlci4gVHJ5IHVzaW5nIHRob3NlIHNl dHRpbmdzIHlvdXJzZWxmLCBhbmQgc2VlPGJyPiZndDsgd2hhdCBjb21lcyBvdXQuPGJyPjxicj5J IHRlc3RlZCBvbiBGcmVlQlNEMTIgKHNpbmNlIGl0IHVzZXMgY2xhbmcgcmF0aGVyIHRoYW4gZ2Nj KSB3aXRoIHRoZTxicj5mb2xsb3dpbmcgZmxhZ3MgYW5kIHRoZSBidWlsZCBjb21wbGV0ZWQgdy9v IGlzc3VlOjxicj48YnI+Q0ZMQUdTPSAtZyAtZnN0YWNrLXByb3RlY3Rvci1hbGwgLWZuby1vbWl0 LWZyYW1lLXBvaW50ZXIgLWZQSUMgLWZQSUUgLU8yPGJyPi1XZm9ybWF0IC1XZm9ybWF0LXNlY3Vy aXR5IC1XZXJyb3I9Zm9ybWF0LXNlY3VyaXR5PGJyPkxERkxBR1M9IC1XbCwteixyZWxybywteixu b3cgLXBpZTxicj5DUFBGTEFHUz0gLURfRk9SVElGWV9TT1VSQ0U9MiAtRF9GT1JUSUZZX1NPVVJD RT0yIC1EX0ZPUlRJRllfU09VUkNFPTI8YnI+PGJyPjxicj5JbiBhbnkgY2FzZSwgSSB0aGluayB3 ZSd2ZSB3ZWxsIGVzdGFibGlzaGVkIHRoZSBwcm9ibGVtIHlvdSdyZSBoaXR0aW5nIGhhczxicj56 ZXJvIHRvIGRvIHdpdGggT3BlbkxEQVAgaW4gYW5kIG9mIGl0c2VsZi4gIFlvdSdsbCBuZWVkIHRv IHRha2UgdGhpcyB1cDxicj5lbHNld2hlcmUuPGJyPjxicj4tLVF1YW5haDxicj48YnI+LS08YnI+ PGJyPlF1YW5haCBHaWJzb24tTW91bnQ8YnI+UHJvZHVjdCBBcmNoaXRlY3Q8YnI+U3ltYXMgQ29y cG9yYXRpb248YnI+UGFja2FnZWQsIGNlcnRpZmllZCwgYW5kIHN1cHBvcnRlZCBMREFQIHNvbHV0 aW9ucyBwb3dlcmVkIGJ5IE9wZW5MREFQOjxicj4mbHQ7aHR0cDovL3d3dy5zeW1hcy5jb20mZ3Q7 PGJyPjxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+ --b1_d8637dbb120a529f4f26d43d4b089cee--

1 0

(ITS#8969) LMDB page_split tweak
by hyc＠openldap.org 31 Jan '19

31 Jan '19

Full_Name: Howard Chu Version: LMDB 0.9 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.233.38.213) Submitted by: hyc In mdb_page_split, we should use the fine-grained search for split point a little more often, to avoid MDB_PAGE_FULL errors.

1 0

(ITS#8968) Async connect mode does not work on Solaris
by vsmith＠interlinknetworks.com 31 Jan '19

31 Jan '19

Full_Name: Vernon Smith Version: 2.4.47 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2601:40d:4300:679a:c0c9:ced:d06f:39a4) I have managed to upgrade to version 2.4.47 libldap libraries using the Linux OS and async connect mode works fine. But when I tried to upgrade to 2.4.47 using Solaris OS and use async connect mode, no connections could be established to the ldap server. The libldap code did not even send the ldap request to the ldap server. The ldap debug trace showed it just freeing the request and returned an unable to connect. I traced the issue to the routine ldap_int_flush_request which checks the sock_errno return code for EAGAIN but Solaris 10 returns ENOTCONN. This error code seems to mean the same thing as EAGAIN. I changed the code to test for either return code and the async connect works for both Linux and Solaris now. Here is may patch. diff --git a/libraries/libldap/request.c b/libraries/libldap/request.c index 9355d7e..321b79f 100644 --- a/libraries/libldap/request.c +++ b/libraries/libldap/request.c @@ -184,7 +184,7 @@ ldap_int_flush_request( LDAP_ASSERT_MUTEX_OWNER( &ld->ld_conn_mutex ); if ( ber_flush2( lc->lconn_sb, lr->lr_ber, LBER_FLUSH_FREE_NEVER ) != 0 ) { - if ( sock_errno() == EAGAIN ) { + if (( sock_errno() == EAGAIN ) || ( sock_errno() == ENOTCONN )) { /* need to continue write later */ lr->lr_status = LDAP_REQST_WRITING; ldap_mark_select_write( ld, lc->lconn_sb ); Thanks, Vern

1 0

(ITS#8967) back-mdb "unchecked" limit broken vs. search scope
by h.b.furuseth＠usit.uio.no 30 Jan '19

30 Jan '19

Full_Name: Hallvard Breien Furuseth Version: 2.4.47 OS: Linux URL: Submission from: (NULL) (2001:700:100:202::105) The size.unchecked limit does not seem to consider search scope other than 'base' in back-mdb. $ ldapsearch -LLL -xh localhost:3890 -b l=there '(l=over)' 1.1 dn: l=over,l=here,l=there $ ldapsearch -LLL -xh localhost:3890 -b l=over,l=here,l=there 1.1 Administrative limit exceeded (11) $ ldapsearch -LLL -xh localhost:3890 -b l=over,l=here,l=there -s base 1.1 dn: l=over,l=here,l=there $ cat test.ldif dn: l=there objectClass: locality dn: l=here,l=there objectClass: locality dn: l=over,l=here,l=there objectClass: locality dn: l=under,l=here,l=there objectClass: locality $ cat test.conf include schema/core.schema loglevel 0 sizelimit size.unchecked=3 database mdb directory test.db suffix l=there index l,objectClass eq

1 0

Re: (ITS#8957)
by quanah＠symas.com 30 Jan '19

30 Jan '19

--On Wednesday, January 30, 2019 1:44 AM -0500 Vernon Smith <vsmith(a)interlinknetworks.com> wrote: > I Tried to upload it to the openldap ftp server but was not successful so > I am trying the patch again here. > > diff --git a/libraries/libldap/open.c b/libraries/libldap/open.c > index bb81d86..20b3dfc 100644 > --- a/libraries/libldap/open.c > +++ b/libraries/libldap/open.c > @@ -489,7 +489,7 @@ ldap_int_open_connection( > #endif > > #ifdef HAVE_TLS > - if (rc == 0 && ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || > + if ((rc == 0 || rc == -2) && ( ld->ld_options.ldo_tls_mode == > LDAP_OPT_X_TLS_HARD || strcmp( srv->lud_scheme, "ldaps" ) == 0 )) > { > ++conn->lconn_refcnt; /* avoid premature free */ That worked, thanks! --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#8957)
by vsmith＠interlinknetworks.com 30 Jan '19

30 Jan '19

I Tried to upload it to the openldap ftp server but was not successful so I am trying the patch again here. diff --git a/libraries/libldap/open.c b/libraries/libldap/open.c index bb81d86..20b3dfc 100644 --- a/libraries/libldap/open.c +++ b/libraries/libldap/open.c @@ -489,7 +489,7 @@ ldap_int_open_connection( #endif #ifdef HAVE_TLS - if (rc == 0 && ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || + if ((rc == 0 || rc == -2) && ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || strcmp( srv->lud_scheme, "ldaps" ) == 0 )) { ++conn->lconn_refcnt; /* avoid premature free */ Thanks, Vern On Tue, January 29, 2019 12:29 pm, Quanah Gibson-Mount wrote: > --On Tuesday, January 29, 2019 4:51 PM +0000 vsmith(a)interlinknetworks.com > wrote: > > > > >> --- openldap-2.4.47/libraries/libldap/open.c?????? 2018-12-19 >> 10:57:06.000000000 -0500 >> +++ openldap-2.4.47.mod/libraries/libldap/open.c?????? 2019-01-26 >> 18:24:48.000000000 -0500 >> @@ -440,7 +440,7 @@ >> ??#endif >> >> >> ??#ifdef HAVE_TLS >> -?????? if (rc == 0 && ( ld->ld_options.ldo_tls_mode == >> LDAP_OPT_X_TLS_HARD || +?????? if ((rc == 0 || rc == -2) && ( >> ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || ???????? ?????? strcmp( >> srv->lud_scheme, "ldaps" ) == 0 )) ???????? { >> ???????? ?????? ++conn->lconn_refcnt;?????? /* avoid premature free */ >> > > This is not a valid patch. I don't know if it's your email client that is > destroying the patch? I suggest uploading it to the FTP site and responding with the > link to the file. > > Thanks, > Quanah > > > > -- > > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > >

1 0

(ITS#8966) changelog support for syncrepl
by hyc＠openldap.org 30 Jan '19

30 Jan '19

Full_Name: Howard Chu Version: 2.5 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.233.38.213) Submitted by: hyc The syncrepl consumer has had stubs for changelog support ever since delta-syncrepl was added using the accesslog overlay. Time to flesh out the rest of it.

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