openldap-bugs May 2015

openldap-bugs@openldap.org

26 participants
101 discussions

Re: (ITS#8140) ssf is hard coded to log as zero, even if it is non-zero
by hyc＠symas.com 12 May '15

12 May '15

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.52.177) > > > bind.c hard codes the output of the ssf= line in some of the stats logging to be > zero, even if the connection actually has a higher ssf. For example: Works as designed. The Bind op itself didn't provide any security, so it contributed 0 to the session's ssf. The preceding StartTLS request actually established a security layer, and it correctly logs the ssf from that. Closing this ITS. > > May 11 02:28:06 ldap01 slapd[33839]: conn=153267 fd=86 TLS established > tls_ssf=256 ssf=256 tls_proto=TLSv1 tls_cipher=AES256-SHA > May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND > dn="uid=zimbra,cn=admins,cn=zimbra" method=128 > May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND > dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0%%0 > May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 RESULT tag=97 err=0 text= > > > Note how we have mech=SIMPLE, ssf=0 > > Since we ran startTLS, and it was established, we clearly do NOT have an ssf of > zero. the ssf=0 bit is *hard coded* in bind.c in the fe_op_bind_success > function: > > /* log authorization identity */ > Statslog( LDAP_DEBUG_STATS, > "%s BIND dn=\"%s\" mech=%s ssf=0\n", > op->o_log_prefix, > op->o_conn->c_dn.bv_val, op->orb_mech.bv_val, 0, 0 ); > > > There's a similar block in do_bind for anonymous binds as well: > > if ( !BER_BVISEMPTY( &op->o_conn->c_dn ) ) { > /* log authorization identity demotion */ > Statslog( LDAP_DEBUG_STATS, > "%s BIND anonymous mech=implicit ssf=0\n", > op->o_log_prefix, 0, 0, 0, 0 ); > } > > It likely should be changed to use: > > op->o_conn->c_ssf > > > -- -- 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#8140) ssf is hard coded to log as zero, even if it is non-zero
by quanah＠openldap.org 11 May '15

11 May '15

Full_Name: Quanah Gibson-Mount Version: RE24 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) bind.c hard codes the output of the ssf= line in some of the stats logging to be zero, even if the connection actually has a higher ssf. For example: May 11 02:28:06 ldap01 slapd[33839]: conn=153267 fd=86 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1 tls_cipher=AES256-SHA May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND dn="uid=zimbra,cn=admins,cn=zimbra" method=128 May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0%%0 May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 RESULT tag=97 err=0 text= Note how we have mech=SIMPLE, ssf=0 Since we ran startTLS, and it was established, we clearly do NOT have an ssf of zero. the ssf=0 bit is *hard coded* in bind.c in the fe_op_bind_success function: /* log authorization identity */ Statslog( LDAP_DEBUG_STATS, "%s BIND dn=\"%s\" mech=%s ssf=0\n", op->o_log_prefix, op->o_conn->c_dn.bv_val, op->orb_mech.bv_val, 0, 0 ); There's a similar block in do_bind for anonymous binds as well: if ( !BER_BVISEMPTY( &op->o_conn->c_dn ) ) { /* log authorization identity demotion */ Statslog( LDAP_DEBUG_STATS, "%s BIND anonymous mech=implicit ssf=0\n", op->o_log_prefix, 0, 0, 0, 0 ); } It likely should be changed to use: op->o_conn->c_ssf

1 0

Re: (ITS#8125) MMR throws away valid changes causing drift
by quanah＠zimbra.com 11 May '15

11 May '15

--On Monday, May 11, 2015 7:32 PM +0000 quanah(a)zimbra.com wrote: > The existing entry drift seems to be related to the locked up replication > that occured because of a bug in openssl. So the real issue is just the > entries that weren't created, which is a current known limitation of > syncrepl refresh that needs fixing. Howard suggests that at least in the delta-syncrepl case, we can modify syncprov to use the accesslog as the memory for its syncprov session log rather than the session log used with standard syncrepl. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8138) regarding some issues with SIDs
by quanah＠zimbra.com 11 May '15

11 May '15

--On Monday, May 11, 2015 8:35 AM +0000 nehadixit89(a)gmail.com wrote: > Full_Name: neha dixit > Version: 2.3 OpenLDAP 2.3 is not a supported piece of software. This ITS will be closed. In addition, the ITS system is for reporting bugs, not general usage questions. Please upgrade to a supported OpenLDAP release, and if you have questions, follow up on the openldap-technical mailing list. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8125) MMR throws away valid changes causing drift
by quanah＠zimbra.com 11 May '15

11 May '15

--On Friday, May 08, 2015 7:56 PM +0000 quanah(a)zimbra.com wrote: > > > --On May 4, 2015 at 8:00:45 PM +0000 openldap-its(a)OpenLDAP.org wrote: > > > In addition to the missing entries, multiple differences exist for > existing entries as well. At this point, it seems that replication with > 2.4.41 is entirely unsafe. The existing entry drift seems to be related to the locked up replication that occured because of a bug in openssl. So the real issue is just the entries that weren't created, which is a current known limitation of syncrepl refresh that needs fixing. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8139) regarding some issues with SIDs
by nehadixit89＠gmail.com 11 May '15

11 May '15

Full_Name: neha dixit Version: 2.3 OS: cent os 5.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (122.160.18.128) our previous employee has integrated samba with ldap and server is working fine. but now when i create new user using smbldap tools ,i m able to see them by getent command.My main concern is that when i tried to logon on windows with the same credentials and it prompts with error that device attached to this system fails . also when i check the issue in logs then it show that user sid is different with primary group sid.also sid is changed in smbldap.conf file. i m unable to troubleshoot that.i would be highly pleased if u solve my problem.

1 0

(ITS#8138) regarding some issues with SIDs
by nehadixit89＠gmail.com 11 May '15

11 May '15

1 0

Re: (ITS#8125) MMR throws away valid changes causing drift
by quanah＠zimbra.com 08 May '15

08 May '15

--On May 4, 2015 at 8:00:45 PM +0000 openldap-its(a)OpenLDAP.org wrote: In addition to the missing entries, multiple differences exist for existing entries as well. At this point, it seems that replication with 2.4.41 is entirely unsafe. @@ -187797,6 +187797,7 @@ zimbraAccountStatus: active zimbraAuthTokens: 1001665890|1430683289367|8.6.0_GA_1153 zimbraAuthTokens: 1429612485|1430681470808|8.6.0_GA_1153 +zimbraAuthTokens: 1452180966|1430677629732|8.6.0_GA_1153 zimbraAuthTokens: 1844325568|1430677341824|8.6.0_GA_1153 zimbraAuthTokens: 1880697989|1430683571359|8.6.0_GA_1153 zimbraAuthTokens: 1954510867|1430680813216|8.6.0_GA_1153 @@ -187808,7 +187809,7 @@ zimbraCOSId: 6a0277ec-2ace-4b16-9764-6fe02f8c7f62 zimbraCreateTimestamp: 20150427191452Z zimbraId: c4cc5985-1727-4446-a196-1cbef2fd9e8a -zimbraLastLogonTimestamp: 20150501182221Z +zimbraLastLogonTimestamp: 20150501182703Z zimbraMailDeliveryAddress: xyz(a)somewhere.com zimbraMailHost: zm-mbs18.neonova.net zimbraMailQuota: 16106127360 @@ -557800,6 +557801,7 @@ zimbraAuthTokens: 1153410464|1430794333078|8.6.0_GA_1153 zimbraAuthTokens: 1153875370|1430796671000|8.6.0_GA_1153 zimbraAuthTokens: 115391065|1430806341396|8.6.0_GA_1153 +zimbraAuthTokens: 1157520768|1430548147751|8.6.0_GA_1153 zimbraAuthTokens: 1187850134|1430806463699|8.6.0_GA_1153 zimbraAuthTokens: 1192041973|1430794095671|8.6.0_GA_1153 zimbraAuthTokens: 1200977988|1430807243978|8.6.0_GA_1153 @@ -557812,6 +557814,7 @@ zimbraAuthTokens: 1229145474|1430807429549|8.6.0_GA_1153 zimbraAuthTokens: 1230922062|1430797919322|8.6.0_GA_1153 zimbraAuthTokens: 1240838648|1430793498690|8.6.0_GA_1153 +zimbraAuthTokens: 1245512453|1430548279974|8.6.0_GA_1153 zimbraAuthTokens: 1256797348|1430790405205|8.6.0_GA_1153 zimbraAuthTokens: 125774918|1430789944147|8.6.0_GA_1153 zimbraAuthTokens: 1257992365|1430800900512|8.6.0_GA_1153 @@ -557821,6 +557824,7 @@ zimbraAuthTokens: 1291211579|1430793942471|8.6.0_GA_1153 zimbraAuthTokens: 1294660932|1430796182543|8.6.0_GA_1153 zimbraAuthTokens: 1299240495|1430807682002|8.6.0_GA_1153 +zimbraAuthTokens: 1303662472|1430548232316|8.6.0_GA_1153 zimbraAuthTokens: 1309389194|1430801132708|8.6.0_GA_1153 zimbraAuthTokens: 1316038520|1430802345713|8.6.0_GA_1153 zimbraAuthTokens: 1323416810|1430775076568|8.6.0_GA_1153 @@ -557888,6 +557892,7 @@ zimbraAuthTokens: 1546458862|1430782672619|8.6.0_GA_1153 zimbraAuthTokens: 155006363|1430792026242|8.6.0_GA_1153 zimbraAuthTokens: 1554772102|1430787555656|8.6.0_GA_1153 +zimbraAuthTokens: 1555500886|1430548271932|8.6.0_GA_1153 zimbraAuthTokens: 1560251088|1430793442122|8.6.0_GA_1153 zimbraAuthTokens: 1560280871|1430777440334|8.6.0_GA_1153 zimbraAuthTokens: 1561800299|1430806414358|8.6.0_GA_1153 @@ -557929,6 +557934,7 @@ zimbraAuthTokens: 1713221378|1430795062424|8.6.0_GA_1153 zimbraAuthTokens: 1714081224|1430794690175|8.6.0_GA_1153 zimbraAuthTokens: 1719102352|1430787580315|8.6.0_GA_1153 +zimbraAuthTokens: 1721546851|1430548275954|8.6.0_GA_1153 zimbraAuthTokens: 1722045342|1430794777719|8.6.0_GA_1153 zimbraAuthTokens: 1728013476|1430807125376|8.6.0_GA_1153 zimbraAuthTokens: 1730079937|1430800179238|8.6.0_GA_1153 @@ -557939,6 +557945,7 @@ zimbraAuthTokens: 1745425399|1430796457601|8.6.0_GA_1153 zimbraAuthTokens: 1752670040|1430789168438|8.6.0_GA_1153 zimbraAuthTokens: 1760000546|1430796630874|8.6.0_GA_1153 +zimbraAuthTokens: 1760771363|1430548094582|8.6.0_GA_1153 zimbraAuthTokens: 1764080232|1430788720545|8.6.0_GA_1153 zimbraAuthTokens: 1764393930|1430769111435|8.6.0_GA_1153 zimbraAuthTokens: 1767121722|1430800106951|8.6.0_GA_1153 @@ -557961,9 +557968,11 @@ zimbraAuthTokens: 1818662300|1430785463584|8.6.0_GA_1153 zimbraAuthTokens: 1819397934|1430784129509|8.6.0_GA_1153 zimbraAuthTokens: 1825833485|1430792892690|8.6.0_GA_1153 +zimbraAuthTokens: 1826263844|1430548283971|8.6.0_GA_1153 zimbraAuthTokens: 1826635337|1430783161924|8.6.0_GA_1153 zimbraAuthTokens: 1828370704|1430798363104|8.6.0_GA_1153 zimbraAuthTokens: 184971068|1430794694175|8.6.0_GA_1153 +zimbraAuthTokens: 1852733329|1430548280003|8.6.0_GA_1153 zimbraAuthTokens: 1854808177|1430794699578|8.6.0_GA_1153 zimbraAuthTokens: 1856036969|1430801152796|8.6.0_GA_1153 zimbraAuthTokens: 1856540960|1430796150392|8.6.0_GA_1153 @@ -558010,6 +558019,7 @@ zimbraAuthTokens: 2030397720|1430788935660|8.6.0_GA_1153 zimbraAuthTokens: 2033511890|1430788572002|8.6.0_GA_1153 zimbraAuthTokens: 2035641769|1430800861823|8.6.0_GA_1153 +zimbraAuthTokens: 20415307|1430547981772|8.6.0_GA_1153 zimbraAuthTokens: 2042478638|1430807440122|8.6.0_GA_1153 zimbraAuthTokens: 2053877671|1430796197464|8.6.0_GA_1153 zimbraAuthTokens: 2059018018|1430796466336|8.6.0_GA_1153 @@ -558060,6 +558070,7 @@ zimbraAuthTokens: 335636684|1430792575890|8.6.0_GA_1153 zimbraAuthTokens: 335985202|1430801830053|8.6.0_GA_1153 zimbraAuthTokens: 345836372|1430800522916|8.6.0_GA_1153 +zimbraAuthTokens: 353782778|1430548279978|8.6.0_GA_1153 zimbraAuthTokens: 357224412|1430799078650|8.6.0_GA_1153 zimbraAuthTokens: 359847881|1430806579447|8.6.0_GA_1153 zimbraAuthTokens: 364380894|1430784519780|8.6.0_GA_1153 @@ -558086,6 +558097,7 @@ zimbraAuthTokens: 464892423|1430792026225|8.6.0_GA_1153 zimbraAuthTokens: 465832041|1430796118188|8.6.0_GA_1153 zimbraAuthTokens: 470587431|1430790706176|8.6.0_GA_1153 +zimbraAuthTokens: 488520030|1430548271921|8.6.0_GA_1153 zimbraAuthTokens: 493433000|1430789116600|8.6.0_GA_1153 zimbraAuthTokens: 49927151|1430800597298|8.6.0_GA_1153 zimbraAuthTokens: 505233009|1430803732532|8.6.0_GA_1153 @@ -558119,6 +558131,7 @@ zimbraAuthTokens: 624216082|1430790986205|8.6.0_GA_1153 zimbraAuthTokens: 627453014|1430802588253|8.6.0_GA_1153 zimbraAuthTokens: 63479916|1430800763552|8.6.0_GA_1153 +zimbraAuthTokens: 636439348|1430548271924|8.6.0_GA_1153 zimbraAuthTokens: 638569970|1430766646718|8.6.0_GA_1153 zimbraAuthTokens: 642528535|1430793436206|8.6.0_GA_1153 zimbraAuthTokens: 653581266|1430803568548|8.6.0_GA_1153 @@ -558131,12 +558144,14 @@ zimbraAuthTokens: 674880688|1430790542019|8.6.0_GA_1153 zimbraAuthTokens: 678557445|1430792426265|8.6.0_GA_1153 zimbraAuthTokens: 688306806|1430789944170|8.6.0_GA_1153 +zimbraAuthTokens: 692909864|1430548275944|8.6.0_GA_1153 zimbraAuthTokens: 695873279|1430791878331|8.6.0_GA_1153 zimbraAuthTokens: 702220076|1430791770891|8.6.0_GA_1153 zimbraAuthTokens: 702905805|1430793051338|8.6.0_GA_1153 zimbraAuthTokens: 703978454|1430801188894|8.6.0_GA_1153 zimbraAuthTokens: 704499344|1430797009784|8.6.0_GA_1153 zimbraAuthTokens: 709844890|1430790284534|8.6.0_GA_1153 +zimbraAuthTokens: 712623687|1430548275943|8.6.0_GA_1153 zimbraAuthTokens: 714322774|1430801693731|8.6.0_GA_1153 zimbraAuthTokens: 714539921|1430794312192|8.6.0_GA_1153 zimbraAuthTokens: 719501426|1430806353190|8.6.0_GA_1153 @@ -906794,14 +906809,20 @@ uid: something userPassword:: a hash zimbraAccountStatus: active +zimbraAuthTokens: 1076665182|1430495517704|8.6.0_GA_1153 +zimbraAuthTokens: 1194289445|1430495472230|8.6.0_GA_1153 +zimbraAuthTokens: 1400191457|1430488755054|8.6.0_GA_1153 zimbraAuthTokens: 1446436024|1430910444064|8.6.0_GA_1153 zimbraAuthTokens: 1494232116|1430754183294|8.6.0_GA_1153 zimbraAuthTokens: 1548373083|1430859654841|8.6.0_GA_1153 +zimbraAuthTokens: 1549007812|1430488727192|8.6.0_GA_1153 zimbraAuthTokens: 1586033245|1430759173317|8.6.0_GA_1153 zimbraAuthTokens: 1751858048|1430924809541|8.6.0_GA_1153 +zimbraAuthTokens: 1800356229|1430488677708|8.6.0_GA_1153 zimbraAuthTokens: 2062630693|1430852313888|8.6.0_GA_1153 zimbraAuthTokens: 480907313|1430754137307|8.6.0_GA_1153 zimbraAuthTokens: 718652654|1430852353198|8.6.0_GA_1153 +zimbraAuthTokens: 800231695|1430488640026|8.6.0_GA_1153 zimbraAuthTokens: 911489049|1430919384737|8.6.0_GA_1153 zimbraCOSId: 6a0277ec-2ace-4b16-9764-6fe02f8c7f62 zimbraCreateTimestamp: 20150407152511Z @@ -2342424,13 +2342445,11 @@ uid: something userPassword:: a hash zimbraAccountStatus: active -zimbraAuthTokens: 1032074923|1430678006084|8.6.0_GA_1153 -zimbraAuthTokens: 1359481243|1430678139287|8.6.0_GA_1153 zimbraAuthTokens: 1367205599|1430685608493|8.6.0_GA_1153 zimbraAuthTokens: 146136864|1430743294805|8.6.0_GA_1153 -zimbraAuthTokens: 1583721154|1430678002509|8.6.0_GA_1153 zimbraAuthTokens: 1938799710|1430831569979|8.6.0_GA_1153 -zimbraAuthTokens: 326869791|1430678012645|8.6.0_GA_1153 +zimbraAuthTokens: 1986204084|1430485163391|8.6.0_GA_1153 +zimbraAuthTokens: 701958474|1430488599819|8.6.0_GA_1153 zimbraCOSId: 6a0277ec-2ace-4b16-9764-6fe02f8c7f62 zimbraCreateTimestamp: 20150311184123Z zimbraCsrfTokenData: data @@ -2977160,8 +2977179,8 @@ uid: something userPassword: a hash zimbraAccountStatus: active -zimbraAuthTokens: 1592805688|1430678263487|8.6.0_GA_1153 zimbraAuthTokens: 1840536155|1430747750113|8.6.0_GA_1153 +zimbraAuthTokens: 297688289|1430677809486|8.6.0_GA_1153 zimbraAuthTokens: 447463167|1430585978383|8.6.0_GA_1153 zimbraCOSId: 6a0277ec-2ace-4b16-9764-6fe02f8c7f62 zimbraCreateTimestamp: 20150407152611Z @@ -4051413,7 +4051432,6 @@ uid: something userPassword:: a hash zimbraAccountStatus: active -zimbraAuthTokens: 1906714231|1430457251759|8.6.0_GA_1153 zimbraAuthTokens: 637421329|1430881121421|8.6.0_GA_1153 zimbraCOSId: 6a0277ec-2ace-4b16-9764-6fe02f8c7f62 zimbraCreateTimestamp: 20150324191333Z @@ -5306187,7 +5306205,6 @@ userPassword:: a hash zimbraAccountStatus: active zimbraAuthTokens: 1215263276|1430662360810|8.6.0_GA_1153 -zimbraAuthTokens: 2103162606|1430678212226|8.6.0_GA_1153 zimbraAuthTokens: 31692696|1430712827710|8.6.0_GA_1153 zimbraAuthTokens: 496395190|1430702599395|8.6.0_GA_1153 zimbraCOSId: 6a0277ec-2ace-4b16-9764-6fe02f8c7f62 @@ -7689287,6 +7689304,7 @@ userPassword:: a hash zimbraAccountStatus: active zimbraAuthTokens: 1361047436|1430788305556|8.6.0_GA_1153 +zimbraAuthTokens: 1379747754|1430499334346|8.6.0_GA_1153 zimbraAuthTokens: 1584426902|1430875712010|8.6.0_GA_1153 zimbraAuthTokens: 1927293924|1430875661923|8.6.0_GA_1153 zimbraAuthTokens: 979685923|1430788353488|8.6.0_GA_1153 @@ -8198997,8 +8199015,10 @@ uid: something userPassword:: a hash zimbraAccountStatus: active +zimbraAuthTokens: 111522850|1430323733525|8.6.0_GA_1153 zimbraAuthTokens: 1643425923|1430886776671|8.6.0_GA_1153 zimbraAuthTokens: 1728545135|1430720880858|8.6.0_GA_1153 +zimbraAuthTokens: 757970470|1430493817783|8.6.0_GA_1153 zimbraCOSId: 6a0277ec-2ace-4b16-9764-6fe02f8c7f62 zimbraCreateTimestamp: 20150415194756Z zimbraId: 5147a109-a13b-4264-985e-c1e4999261da @ -9048815,7 +9048835,6 @@ uid: something userPassword:: a hash zimbraAccountStatus: active -zimbraAuthTokens: 820727281|1430672042988|8.6.0_GA_1153 zimbraCOSId: 6a0277ec-2ace-4b16-9764-6fe02f8c7f62 zimbraCreateTimestamp: 20150311185757Z zimbraCsrfTokenData: 69643d33363a65643532303936632d636336392d346136362d626137342d3937366538643337616365363b6578703d31333a313432383738303434383930303b7369643d31303a2d3730363739343338353b:f0a19918939e46e2a5a1b69ba91 710de:1428780448900 @@ -12477050,12 +12477043,12 @@ createTimestamp: 20141208203040Z creatorsName: uid=zimbra,cn=admins,cn=zimbra displayName: something -entryCSN: 20150426144745.317031Z#000000#001#000000 +entryCSN: 20150501183105.859472Z#000000#002#000000 entryUUID: d1d1f11e-1364-1034-8f85-d75f97c57676 givenName: something mail: someone(a)somewhere.net modifiersName: uid=zimbra,cn=admins,cn=zimbra -modifyTimestamp: 20150426144745Z +modifyTimestamp: 20150501183105Z objectClass: amavisAccount objectClass: inetOrgPerson objectClass: zimbraAccount (etc) --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8127) 32 bit windows build fails with mingw
by hyc＠symas.com 07 May '15

07 May '15

ebackes(a)symas.com wrote: > Hello, Frank. > >> thanks for your patch. But since I am compilling 32 Bit, it doesn't work. >> I modified your patch to >> #define ftello ftell >> Then it works. > > Hm; that should work on 32bit windows. (it does for me!) As I already noted, ftelli64's availability depends on the version of the MSVCRT DLL on the system. Frank's MinGW is apparently too old to contain the ftelli64 symbol in the libmsvcrt import library. > Using > ftell() will limit you to 2GB files. Then again, that particular case > is only for proress-reporting. If your LDIF to be slapadd'd is less > than 2GB, it won't matter. > >> But I still have the GetFileSizeEx problem. >> I use MinGW-5.1.6 and here is my installed.ini: > > I'll have to try that. In the mean time, I've had more success > building with the version from winbuilds.org. Always quote specific version numbers. The MSYS I use is MINGW32_NT-6.1 VIEL64 1.0.17(0.48/3/2) 2011-04-24 23:39 i686 Msys I'm using MinGW from mingw-w64 (builds both 32 and 64 bit binaries) version 1.0.8. http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/ -- -- 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#8127) 32 bit windows build fails with mingw
by hyc＠symas.com 07 May '15

07 May '15

Frank.Offermanns(a)caseris.de wrote: > Dies ist eine mehrteilige Nachricht im MIME-Format. > --=_alternative 00233070C1257E3D_= > Content-Type: text/plain; charset="US-ASCII" > > Hi, > > thanks for your patch. But since I am compilling 32 Bit, it doesn't work. > I modified your patch to > #define ftello ftell > Then it works. But that will only work for input LDIF files smaller than 4GB. A better fix is now committed in git master. > > But I still have the GetFileSizeEx problem. GetFileSizeEx is a part of the Win32 API since Windows XP. https://msdn.microsoft.com/en-us/library/windows/desktop/aa364957%28v=vs.85… Sounds like your MinGW is too old or needs a fix. There is nothing to fix in OpenLDAP source for this problem. This ITS is now resolved. > I use MinGW-5.1.6 and here is my installed.ini: > [settings] > mirror= > installtype=current > > [components] > runtime=mingwrt-3.17-mingw32-dev.tar.gz > w32api=w32api-3.14-mingw32-dev.tar.gz > binutils=binutils-2.20-1-mingw32-bin.tar.gz > core=gcc-core-3.4.5-20060117-3.tar.gz > gpp=gcc-g++-3.4.5-20060117-3.tar.gz > g77= > ada= > java= > objc=gcc-objc-3.4.5-20060117-3.tar.gz > make=make-3.81-20090914-mingw32-bin.tar.gz > runtimeDLL=mingwrt-3.17-mingw32-dll.tar.gz > > Regards, > Frank > > -- -- 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

← Newer
1
...
4
5
6
7
8
9
10
11
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2015