Re: (ITS#5104) OpenLDAP build breaks with SSL
by ando＠sys-net.it
Richard Beckett wrote:
> Pierangelo, I really need help. My neck is on the block with this one.
> It is preventing me from accessing Active directory since that requires
> SASL.
1) Your issue is seems not to be an issue, since it seems to work for
anyone else, including myself. If I can't reproduce, I can't fix it.
2) I don't have time.
3) If I had time, I'd spend it working for the community, not for a
single (unless well paid), but you keep posting only to me.
4) The fact I initially answered your request doesn't mean you gained a
perpetual support ticket until your issue is solved.
5) If you post to the ITS there are chances someone else, either with
the same problem, or with better understanding of the issue can help.
I consider my participation to this ITS closed.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 5 months
Re: (ITS#5102) back-perl build issues
by ando＠sys-net.it
Kurt Zeilenga wrote:
>> ConfigReply is declared in slapd/config.h; could it be another,
>> system-related config.h is present in an earlier include path?
>>
>> Even though, I see in the above cc command-line -I .. is present...
>
> Personally, I think have -I., -I.., etc. is really bad. This causes
> #include "config.h"
> and
> #include <config.h>
>
> to be equivalent. However, there could be both a local config.h and a
> config.h somewhere in the system include directory.
>
> I would be better if slapd/config.h was included here by:
> #include "../config.h"
>
> and -I.. not be added to the include path. It possible -I.. is causing
> a system header to be eclipsed by the local header.
-I.. is needed to include slap.h, proto-slap.h, ...
I'd rather rename config.h, which is quite generic, into slapconf.h or so.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 5 months
Re: (ITS#5102) back-perl build issues
by quanah＠zimbra.com
--On Saturday, August 25, 2007 6:16 AM +0000 kurt(a)OpenLDAP.org wrote:
> Personally, I think have -I., -I.., etc. is really bad. This causes
> #include "config.h"
> and
> #include <config.h>
>
> to be equivalent. However, there could be both a local config.h and
> a config.h somewhere in the system include directory.
>
> I would be better if slapd/config.h was included here by:
> #include "../config.h"
>
> and -I.. not be added to the include path. It possible -I.. is
> causing a system header to be eclipsed by the local header.
> Namely, /opt/local/lib/perl5/5.8.8/darwin-2level/CORE/config.h.
This issue seems to hit Mac systems a lot, dunno why. But I've seen it
with several things now that touch perl.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 5 months
Re: (ITS#5102) back-perl build issues
by kurt＠OpenLDAP.org
On Aug 25, 2007, at 5:35 AM, ando(a)sys-net.it wrote:
> kurt(a)OpenLDAP.org wrote:
>
>>>> Entering directory `/Users/kurt/Work/devel/servers/slapd/back-perl'
>>>> /bin/sh ../../..//libtool --tag=disable-shared --mode=compile cc -
>>>> g -O2
>>>> -I../../../include -I../../../include -I.. -I./.. -I/opt/
>>>> local/include
>>>> -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -
>>>> pipe
>>>> -Wdeclaration-after-statement -I/opt/local/include
>>>> -I/opt/local/lib/perl5/5.8.8/darwin-2level/CORE -I/usr/pkg/
>>>> include
>>>> -I/usr/pkg/include/db45 -c init.c
>>>> cc -g -O2 -I../../../include -I../../../include -I.. -I./..
>>>> -I/opt/local/include -fno-common -DPERL_DARWIN -no-cpp-precomp
>>>> -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/opt/
>>>> local/include
>>>> -I/opt/local/lib/perl5/5.8.8/darwin-2level/CORE -I/usr/pkg/include
>>>> -I/usr/pkg/include/db45 -c init.c -o init.o
>>>> init.c:90: error: parse error before 'ConfigReply'
>
> ConfigReply is declared in slapd/config.h; could it be another,
> system-related config.h is present in an earlier include path?
>
> Even though, I see in the above cc command-line -I .. is present...
Personally, I think have -I., -I.., etc. is really bad. This causes
#include "config.h"
and
#include <config.h>
to be equivalent. However, there could be both a local config.h and
a config.h somewhere in the system include directory.
I would be better if slapd/config.h was included here by:
#include "../config.h"
and -I.. not be added to the include path. It possible -I.. is
causing a system header to be eclipsed by the local header.
Namely, /opt/local/lib/perl5/5.8.8/darwin-2level/CORE/config.h.
>
> p.
>
>
>
> Ing. Pierangelo Masarati
> OpenLDAP Core Team
>
> SysNet s.r.l.
> via Dossi, 8 - 27100 Pavia - ITALIA
> http://www.sys-net.it
> ---------------------------------------
> Office: +39 02 23998309
> Mobile: +39 333 4963172
> Email: pierangelo.masarati(a)sys-net.it
> ---------------------------------------
>
>
>
15 years, 5 months
Re: (ITS#5102) back-perl build issues
by ando＠sys-net.it
kurt(a)OpenLDAP.org wrote:
>>> Entering directory `/Users/kurt/Work/devel/servers/slapd/back-perl'
>>> /bin/sh ../../..//libtool --tag=disable-shared --mode=compile cc -
>>> g -O2
>>> -I../../../include -I../../../include -I.. -I./.. -I/opt/
>>> local/include
>>> -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe
>>> -Wdeclaration-after-statement -I/opt/local/include
>>> -I/opt/local/lib/perl5/5.8.8/darwin-2level/CORE -I/usr/pkg/include
>>> -I/usr/pkg/include/db45 -c init.c
>>> cc -g -O2 -I../../../include -I../../../include -I.. -I./..
>>> -I/opt/local/include -fno-common -DPERL_DARWIN -no-cpp-precomp
>>> -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/opt/
>>> local/include
>>> -I/opt/local/lib/perl5/5.8.8/darwin-2level/CORE -I/usr/pkg/include
>>> -I/usr/pkg/include/db45 -c init.c -o init.o
>>> init.c:90: error: parse error before 'ConfigReply'
ConfigReply is declared in slapd/config.h; could it be another,
system-related config.h is present in an earlier include path?
Even though, I see in the above cc command-line -I .. is present...
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 5 months
Re: (ITS#5102) back-perl build issues
by kurt＠OpenLDAP.org
On Aug 22, 2007, at 6:04 PM, ando(a)sys-net.it wrote:
> kurt(a)OpenLDAP.org wrote:
>
>> With perl v5.8.8 from macports (recently upgraded)
Switching to the MacOS X default perl doesn't help...
> Works fine here (Linux)
>
>> Entering directory `/Users/kurt/Work/devel/servers/slapd/back-perl'
>> /bin/sh ../../..//libtool --tag=disable-shared --mode=compile cc -
>> g -O2
>> -I../../../include -I../../../include -I.. -I./.. -I/opt/
>> local/include
>> -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe
>> -Wdeclaration-after-statement -I/opt/local/include
>> -I/opt/local/lib/perl5/5.8.8/darwin-2level/CORE -I/usr/pkg/include
>> -I/usr/pkg/include/db45 -c init.c
>> cc -g -O2 -I../../../include -I../../../include -I.. -I./..
>> -I/opt/local/include -fno-common -DPERL_DARWIN -no-cpp-precomp
>> -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/opt/
>> local/include
>> -I/opt/local/lib/perl5/5.8.8/darwin-2level/CORE -I/usr/pkg/include
>> -I/usr/pkg/include/db45 -c init.c -o init.o
>> init.c:90: error: parse error before 'ConfigReply'
>> init.c: In function 'perl_back_db_init':
>> init.c:92: error: number of arguments doesn't match prototype
>> proto-perl.h:27: error: prototype declaration
>
> This was recently (sort of: 2 weeks ago) changed. Are you sure you
> updated?
Yes.
>
> p.
>
>
>
> Ing. Pierangelo Masarati
> OpenLDAP Core Team
>
> SysNet s.r.l.
> via Dossi, 8 - 27100 Pavia - ITALIA
> http://www.sys-net.it
> ---------------------------------------
> Office: +39 02 23998309
> Mobile: +39 333 4963172
> Email: pierangelo.masarati(a)sys-net.it
> ---------------------------------------
>
>
>
15 years, 5 months
(ITS#5105) 64 bit Windows portability errors in liblber
by alexey.melnikov＠isode.com
Full_Name: Alexey Melnikov
Version: 2.3.28
OS: Windows XP
URL: ftp://ftp.openldap.org/incoming/alexey-melnikov-070824.diff
Submission from: (NULL) (62.3.217.250)
Visual C 8.0 reports warnings when building liblber with /Wp64 (64 bit Windows
portability warnings). The warnings are actually bugs on Windows 64:
bprint.c(269) : warning C4311: 'type cast' : pointer truncation from 'char *' to
'long'
bprint.c(270) : warning C4311: 'type cast' : pointer truncation from 'char *' to
'long'
bprint.c(271) : warning C4311: 'type cast' : pointer truncation from 'char *' to
'long'
bprint.c(308) : warning C4311: 'type cast' : pointer truncation from 'char *' to
'long'
bprint.c(309) : warning C4311: 'type cast' : pointer truncation from 'char *' to
'long'
decode.c(376) : warning C4311: 'type cast' : pointer truncation from 'BerVarray'
to 'long'
decode.c(377) : warning C4312: 'type cast' : conversion from 'unsigned long' to
'berval *' of greater size
decode.c(409) : warning C4311: 'type cast' : pointer truncation from 'BerVarray'
to 'long'
decode.c(409) : warning C4312: 'type cast' : conversion from 'unsigned long' to
'BerVarray' of greater size
Warnings in bprint.c are caused by use of %X which is incorrect on Windows 64.
Portable %p should be used instead.
Problems in decode.c are caused by typecasting a pointer to a long.
Unfortunately on Windows 64 a pointer is 64 bits, while "long" is still 32bits,
which is obviously problematic. The fix is to use typecase to "char *" instead,
as pointer arithmetics will work for it.
I've uploaded the patch as
<ftp://ftp.openldap.org/incoming/alexey-melnikov-070824.diff>
15 years, 5 months
Re: (ITS#5096) [enhancement] back-sql should provide a means to reload schema mapping runtime
by ando＠sys-net.it
ando(a)sys-net.it wrote:
> This is a request enhancement for a means to reload schema mapping run-time,
> without the need to stop slapd. The ideal candidate for this feature seems to
> be back-monitor.
... of course, adding back-config support would probably allow to remove
and add the database again, resulting in the expected behavior.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 5 months
Re: (ITS#5077) syncrepl.add_cmp() infinite loop on swapped values
by hyc＠symas.com
Donn Cave wrote:
> It looks easy enough to me to code up an order independent version that
> will actually work. I would initialize adds[] and dels[] with old & new
> berval pointers, iterate through dels[] and adds[] (nested), and clear
> both on match. The code is easier to follow and empirically I see one
> fewer matches in the cases I tested it on. But that's just a test of
> the algorithm - I haven't sorted out what needs to be done at the end of
> the function where mcur etc. are modified depending on i == j.
The only way to do this right, without dying on an O(n^2) algorithm, is to sort
both arrays first and then walk through them in order as the original code did.
If you want to submit such a patch, please do. I don't have a lot of time to
focus on this at the moment.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 5 months
