Full_Name: Guillaume Rousse Version: 2.3.6 OS: Mandriva linux 2006.0 URL: http://qa.mandriva.com/show_bug.cgi?id=19605 Submission from: (NULL) (128.93.8.181) Using autofs with configuration stored in LDAP triggers kernel segfault on x86_64 platform. Everything works OK with openldap 2.2.7 however. Full details available on distribution bugzilla: http://qa.mandriva.com/show_bug.cgi?id=19605
Please elaborate as to why you believe this problem is due to a bug in OpenLDAP Software and what you believe that bug to be. Kurt At 08:57 AM 11/10/2005, Guillaume.Rousse@inria.fr wrote: >Full_Name: Guillaume Rousse >Version: 2.3.6 >OS: Mandriva linux 2006.0 >URL: http://qa.mandriva.com/show_bug.cgi?id=19605 >Submission from: (NULL) (128.93.8.181) > > >Using autofs with configuration stored in LDAP triggers kernel segfault on >x86_64 platform. Everything works OK with openldap 2.2.7 however. > >Full details available on distribution bugzilla: >http://qa.mandriva.com/show_bug.cgi?id=19605
changed notes changed state Open to Feedback
As noted in bugzilla report, using autofs without ldap-defined configurarion does not trigger any segfault, and rebuilding autofs against an older version of openafs lib (2.2 vs 2.3) make it works correctly. -- The nozzle behind the sprayer tank will be the first one to plug -- The Law of Inverse Visibility
On Thu, 2005-11-10 at 19:12 +0000, Guillaume.Rousse@inria.fr wrote: > As noted in bugzilla report, using autofs without ldap-defined > configurarion does not trigger any segfault, and rebuilding autofs > against an older version of openafs lib (2.2 vs 2.3) make it works > correctly. does the 2.2/2.3 above refer to those "openafs lib" or to OpenLDAP client libraries? The description of the problem seems to indicate that the issue arises when passing from Mandriva's build of OpenLDAP libraries 2.2 to 2.3; this may or may not disveal a problem in OpenLDAP libraries, or their misuse in the client software, or some other interaction with components of the system. However, without further details, it is very unlikely we can progress any further. Can you reveal any useful info, e.g. server logs of the operations (if any) that end up in the client problem? The best would be a stack backtrace of the offending OpenLDAP code, assuming that the crash occurs in OpenLDAP's software. See <http://www.openldap.org/faq/data/cache/59.html> for indications about how to provide useful information. p. Ing. Pierangelo Masarati Responsabile Open Solution SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
On Friday 11 November 2005 01:42, ando@sys-net.it wrote: > On Thu, 2005-11-10 at 19:12 +0000, Guillaume.Rousse@inria.fr wrote: > > As noted in bugzilla report, using autofs without ldap-defined > > configurarion does not trigger any segfault, and rebuilding autofs > > against an older version of openafs lib (2.2 vs 2.3) make it works > > correctly. > > does the 2.2/2.3 above refer to those "openafs lib" or to OpenLDAP > client libraries? OpenLDAP only. AFAIK no openafs libs are involved, this was a typo. I recommended that Guillaume rebuild autofs against libldap2.2_7-devel (which is currently at 2.2.27 and only retained for compatibility reasons) to see if libldap was involved. > The description of the problem seems to indicate that > the issue arises when passing from Mandriva's build of OpenLDAP > libraries 2.2 to 2.3 We have only one patches on the libraries in both 2.2 and 2.3 (http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/SPECS/openldap/openldap-2.2.19-ntlm.patch). Guillaume rebuilt the 2.2 packages on the same system, and also built 2.3.11 (from the cooker tree), which would seem to rule out any compiler-related issues. And note that this issue seems to only affect 64bit platforms (or at least only x86_64 so far). > ; this may or may not disveal a problem in OpenLDAP > libraries, or their misuse in the client software, or some other > interaction with components of the system. I have had reports by personal email of similar problems with samba when using the pdb_ldap backend on x86_64 (whereas I use it personally on x86 with no problems). Unfortunately these reporters did not post bugs or provide any further information. I haven't been able to setup a system to reproduce this on yet (as none of my x86 systems can reproduce it and I only have one x86_64 system available). > However, without further details, it is very unlikely we can progress > any further. Can you reveal any useful info, e.g. server logs of the > operations (if any) that end up in the client problem? The best would > be a stack backtrace of the offending OpenLDAP code, assuming that the > crash occurs in OpenLDAP's software. Since this issue affects samba only when using pdb_ldap, and autofs only when using maps in LDAP, it would appear to be the case. I'll try and get a system up that I can debug this on. Regards, Buchan -- Buchan Milne ISP Systems Specialist B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)
On Fri, 2005-11-11 at 08:12 +0200, Buchan Milne wrote: > On Friday 11 November 2005 01:42, ando@sys-net.it wrote: > > On Thu, 2005-11-10 at 19:12 +0000, Guillaume.Rousse@inria.fr wrote: > > > As noted in bugzilla report, using autofs without ldap-defined > > > configurarion does not trigger any segfault, and rebuilding autofs > > > against an older version of openafs lib (2.2 vs 2.3) make it works > > > correctly. > > > > does the 2.2/2.3 above refer to those "openafs lib" or to OpenLDAP > > client libraries? > > OpenLDAP only. AFAIK no openafs libs are involved, this was a typo. > > I recommended that Guillaume rebuild autofs against libldap2.2_7-devel (which > is currently at 2.2.27 and only retained for compatibility reasons) to see if > libldap was involved. > > > The description of the problem seems to indicate that > > the issue arises when passing from Mandriva's build of OpenLDAP > > libraries 2.2 to 2.3 > > We have only one patches on the libraries in both 2.2 and 2.3 > (http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/SPECS/openldap/openldap-2.2.19-ntlm.patch). > Guillaume rebuilt the 2.2 packages on the same system, and also built 2.3.11 > (from the cooker tree), which would seem to rule out any compiler-related > issues. > > And note that this issue seems to only affect 64bit platforms (or at least > only x86_64 so far). > > > ; this may or may not disveal a problem in OpenLDAP > > libraries, or their misuse in the client software, or some other > > interaction with components of the system. > > I have had reports by personal email of similar problems with samba when using > the pdb_ldap backend on x86_64 (whereas I use it personally on x86 with no > problems). Unfortunately these reporters did not post bugs or provide any > further information. > > I haven't been able to setup a system to reproduce this on yet (as none of my > x86 systems can reproduce it and I only have one x86_64 system available). > > > However, without further details, it is very unlikely we can progress > > any further. Can you reveal any useful info, e.g. server logs of the > > operations (if any) that end up in the client problem? The best would > > be a stack backtrace of the offending OpenLDAP code, assuming that the > > crash occurs in OpenLDAP's software. > > Since this issue affects samba only when using pdb_ldap, and autofs only when > using maps in LDAP, it would appear to be the case. I'm not saying it's not. I'm saying that right now we didn't get to a clear indication of a bug in OpenLDAP, not to mention indications as of where the bug could be. The report, and your message, suggest an issue when OpenLDAP client libraries interact with other software on certain platforms. The problem can be in OpenLDAP, in the client software or in the platform. I'm routinely developing on amd64; one issue I note is that in OpenLDAP 2.3 (as well as in late 2.2, sigh) most of the API used by autofs (after quickly surfing the code) is deprecated, so there might be chances that the compiler's guesses for undeclared functions conflict with the actual arg data sizes. I suggest you (and Guillaume) try to rebuild autofs with LDAP_DEPRECATED explicitly defined (e.g. CPPFLAGS=- DLDAP_DEPRECATED). In any case, I don't think we can easily spot the issue unless some more details are provided. Logs (and, for SIGSEGVs, stack backtraces) usually are my primary inputs. p. Ing. Pierangelo Masarati Responsabile Open Solution SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
Pierangelo Masarati wrote: > On Thu, 2005-11-10 at 19:12 +0000, Guillaume.Rousse@inria.fr wrote: > >>As noted in bugzilla report, using autofs without ldap-defined >>configurarion does not trigger any segfault, and rebuilding autofs >>against an older version of openafs lib (2.2 vs 2.3) make it works >>correctly. > > > does the 2.2/2.3 above refer to those "openafs lib" or to OpenLDAP > client libraries? OpenLDAP client libraries, I'm confused for this stupid typo. > However, without further details, it is very unlikely we can progress > any further. Can you reveal any useful info, e.g. server logs of the > operations (if any) that end up in the client problem? The best would > be a stack backtrace of the offending OpenLDAP code, assuming that the > crash occurs in OpenLDAP's software. I didn't produced server logs because it works OK for all other hosts, so I thought it should be a client side problem. Using --debug flags for starting autofs show it successfuly get the map from LDAP server, just before triggering the segfault: Nov 11 11:49:10 cognac automount[15771]: starting automounter version 4.1.4, path = /home/beaune, maptype = ldap, mapname = ou=auto.home.beaune,ou=autofs,dc=village,dc=inria,dc=fr Nov 11 11:49:10 cognac kernel: automount[15771]: segfault at 0000000055667228 rip 00002aaaab02ea88 rsp 00007fffffa39770 error 4 I ran autofs through gdb, here is stack trace: Starting program: /usr/sbin/automount --timeout=60 /net/graves ldap ou=auto.net.graves,ou=autofs,dc=village,dc=inria,dc=fr Attaching after fork to child process 14590. [tcsetpgrp failed in terminal_inferior: Opération non permise] Program received signal SIGSEGV, Segmentation fault. [Switching to process 14590] 0x00002aaaab02e978 in ldap_set_option () from /usr/lib64/libldap-2.3.so.0 (gdb) bt #0 0x00002aaaab02e978 in ldap_set_option () from /usr/lib64/libldap-2.3.so.0 #1 0x00002aaaaaf00ba8 in do_connect (ctxt=0x555555665740, result_ldap=0x7fffffb51814) at lookup_ldap.c:66 #2 0x00002aaaaaf00e70 in lookup_init (mapfmt=0x2aaaaaf03920 "sun", argc=1, argv=0x7fffffb51a18, context=Variable "context" is not available. ) at lookup_ldap.c:180 #3 0x000055555555aac9 in open_lookup (name=0x7fffffb52a0f "ldap", err_prefix=0x55555555c4dd "", mapfmt=0x0, argc=1, argv=0x7fffffb51a18) at module.c:83 #4 0x0000555555559da3 in main (argc=Variable "argc" is not available. ) at automount.c:1762 I can't have a better stack trace from inside libldap, even if I am sure it has not been stripped. -- The Item of equipment that usually wont start or jams when you need it the most is the pump -- Murphy's Bush Fire Brigade Laws n°21
On Fri, 2005-11-11 at 11:37 +0000, Guillaume.Rousse@inria.fr wrote: > Pierangelo Masarati wrote: > > On Thu, 2005-11-10 at 19:12 +0000, Guillaume.Rousse@inria.fr wrote: > Program received signal SIGSEGV, Segmentation fault. > [Switching to process 14590] > 0x00002aaaab02e978 in ldap_set_option () from /usr/lib64/libldap-2.3.so.0 > (gdb) bt > #0 0x00002aaaab02e978 in ldap_set_option () from > /usr/lib64/libldap-2.3.so.0 > #1 0x00002aaaaaf00ba8 in do_connect (ctxt=0x555555665740, > result_ldap=0x7fffffb51814) at lookup_ldap.c:66 > #2 0x00002aaaaaf00e70 in lookup_init (mapfmt=0x2aaaaaf03920 "sun", argc=1, > argv=0x7fffffb51a18, context=Variable "context" is not available. > ) at lookup_ldap.c:180 > #3 0x000055555555aac9 in open_lookup (name=0x7fffffb52a0f "ldap", > err_prefix=0x55555555c4dd "", mapfmt=0x0, argc=1, argv=0x7fffffb51a18) > at module.c:83 > #4 0x0000555555559da3 in main (argc=Variable "argc" is not available. > ) at automount.c:1762 > > I can't have a better stack trace from inside libldap, even if I am sure > it has not been stripped. Some debugging symbols, at least the line number would have been of help; anyway, this is more and more convincing of my suspicion about some 64 bit issue (I haven't noticed yet on my amd64, though) because ldap_{sg}et_option() do a lot of pointer-to-anytype conversion with explicit casts, and this is a typical good chance for type mismatch because the cast inhibits compiler warnings. Can you try your best to get line numbers out of there? I've downloaded autofs 4.1.3 sources (is it the version you're using?) and the only calls to ldap_set_option() is to set the protocol version; in my copy of the file it occurs at line 58 rather than 66. The datum is an int, so that call should be fine. A LDAP * resulting from a call to ldap_init() is passed after checking it's not NULL. After defining -DLDAP_DEPRECATED, the only warning I get is about an automatic var that could be used uninitialized, in lookup_wild(); this should have nothing to do with your issue (I'll post a note to the developers). Please feedback. p. Ing. Pierangelo Masarati Responsabile Open Solution SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
> After defining -DLDAP_DEPRECATED, the only warning I get is about an > automatic var that could be used uninitialized, in lookup_wild(); this > should have nothing to do with your issue (I'll post a note to the > developers). Never mind, it's already fixed in 4.1.4. p. Ing. Pierangelo Masarati Responsabile Open Solution SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
Pierangelo Masarati wrote: > Some debugging symbols, at least the line number would have been of > help; anyway, this is more and more convincing of my suspicion about > some 64 bit issue (I haven't noticed yet on my amd64, though) because > ldap_{sg}et_option() do a lot of pointer-to-anytype conversion with > explicit casts, and this is a typical good chance for type mismatch > because the cast inhibits compiler warnings. > > Can you try your best to get line numbers out of there? I've rebuild openldap, ensuring -g option is used (which was not the case previously), here it is: (gdb) bt full #0 ldap_set_option (ld=0x55667200, option=17, invalue=0x7fffffb13d44) at options.c:358 lo = Variable "lo" is not available. (gdb) bt #0 ldap_set_option (ld=0x55667200, option=17, invalue=0x7fffffb13d44) at options.c:358 #1 0x00002aaaaaf00ba8 in do_connect (ctxt=0x555555665740, result_ldap=0x7fffffb13d94) at lookup_ldap.c:66 #2 0x00002aaaaaf00e70 in lookup_init (mapfmt=0x2aaaaaf03920 "sun", argc=1, argv=0x7fffffb13f98, context=Variable "context" is not available. ) at lookup_ldap.c:180 #3 0x000055555555aac9 in open_lookup (name=0x7fffffb14a20 "ldap", err_prefix=0x55555555c4dd "", mapfmt=0x0, argc=1, argv=0x7fffffb13f98) at module.c:83 #4 0x0000555555559da3 in main (argc=Variable "argc" is not available. ) at automount.c:1762 > I've downloaded > autofs 4.1.3 sources (is it the version you're using?) and the only > calls to ldap_set_option() is to set the protocol version; in my copy of > the file it occurs at line 58 rather than 66. The datum is an int, so > that call should be fine. A LDAP * resulting from a call to ldap_init() > is passed after checking it's not NULL. We using 4.1.4, with some patches applied, see http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/SPECS/autofs/ for details. -- The sewing machine light usually burns out on Sunday -- Murphy's Laws of Sewing n°16
> Pierangelo Masarati wrote: >> Some debugging symbols, at least the line number would have been of >> help; anyway, this is more and more convincing of my suspicion about >> some 64 bit issue (I haven't noticed yet on my amd64, though) because >> ldap_{sg}et_option() do a lot of pointer-to-anytype conversion with >> explicit casts, and this is a typical good chance for type mismatch >> because the cast inhibits compiler warnings. >> >> Can you try your best to get line numbers out of there? > I've rebuild openldap, ensuring -g option is used (which was not the > case previously), here it is: > > (gdb) bt full > #0 ldap_set_option (ld=0x55667200, option=17, invalue=0x7fffffb13d44) > at options.c:358 > lo = Variable "lo" is not available. > (gdb) bt > #0 ldap_set_option (ld=0x55667200, option=17, invalue=0x7fffffb13d44) > at options.c:358 This appears to be 357: if(ld != NULL) { 358: assert( LDAP_VALID( ld ) ); 359: 360: if( !LDAP_VALID( ld ) ) { Note that this code doesn't really differ from OpenLDAP 2.2's, and it's been there since '99: cvs annotate gives 1.52 (kurt 08-Jun-00): if(ld != NULL) { 1.26 (kdz 28-May-99): assert( LDAP_VALID( ld ) ); 1.26 (kdz 28-May-99): 1.26 (kdz 28-May-99): if( !LDAP_VALID( ld ) ) { Also, I note that "ld" is passed as it is returned by ldap_init() in autofs-4.1.4/modules/lookup_ldap.c; if ldap_init() returned a NULL, ldap_set_option() would not be invoked. None of Mandriva patches seem to affect the ldap-related code. I suspect the real issue is going on in ldap_init(), although I don't see many changes from 2.2 even there. > #1 0x00002aaaaaf00ba8 in do_connect (ctxt=0x555555665740, > result_ldap=0x7fffffb13d94) at lookup_ldap.c:66 > #2 0x00002aaaaaf00e70 in lookup_init (mapfmt=0x2aaaaaf03920 "sun", > argc=1, > argv=0x7fffffb13f98, context=Variable "context" is not available. > ) at lookup_ldap.c:180 > #3 0x000055555555aac9 in open_lookup (name=0x7fffffb14a20 "ldap", > err_prefix=0x55555555c4dd "", mapfmt=0x0, argc=1, argv=0x7fffffb13f98) > at module.c:83 > #4 0x0000555555559da3 in main (argc=Variable "argc" is not available. > ) at automount.c:1762 Did you compile with -DLDAP_DEPRECATED? p. -- Pierangelo Masarati mailto:pierangelo.masarati@sys-net.it Ing. Pierangelo Masarati Responsabile Open Solution SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
Pierangelo Masarati wrote: > Did you compile with -DLDAP_DEPRECATED? I guess you're speaking of autofs here ? No, I did not. Should I try ? -- There is no such place as a convenient foxhole -- Murphy's Military Laws n°95
On Mon, 2005-11-14 at 16:29 +0000, Guillaume.Rousse@inria.fr wrote: > Pierangelo Masarati wrote: > > Did you compile with -DLDAP_DEPRECATED? > I guess you're speaking of autofs here ? No, I did not. Should I try ? Yes. Just in case, as I cannot see a possible difference between OpenLDAP 2.2 and 2.3 up to there. The only noticeable thing that happens during ldap_init() is that global opts get copied into the LDAP handler. Unless the issue is over there (but it would have appeared ages ago...) p. Ing. Pierangelo Masarati Responsabile Open Solution SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
Pierangelo Masarati wrote: > On Mon, 2005-11-14 at 16:29 +0000, Guillaume.Rousse@inria.fr wrote: > >>Pierangelo Masarati wrote: >> >>>Did you compile with -DLDAP_DEPRECATED? >> >>I guess you're speaking of autofs here ? No, I did not. Should I try ? > > > Yes. Just in case, as I cannot see a possible difference between > OpenLDAP 2.2 and 2.3 up to there. The only noticeable thing that > happens during ldap_init() is that global opts get copied into the LDAP > handler. Unless the issue is over there (but it would have appeared > ages ago...) It works OK. It seems to imply all apps build against openldap should define it, otherwise strange things may happen. -- If it's stupid but it works, it ain't stupid -- Murphy's Bush Fire Brigade Laws n°23
changed notes changed state Feedback to Release moved from Incoming to Build
changed state Release to Feedback
On Mon, 2005-11-14 at 21:24 +0100, Guillaume Rousse wrote: > Pierangelo Masarati wrote: > > On Mon, 2005-11-14 at 16:29 +0000, Guillaume.Rousse@inria.fr wrote: > > > >>Pierangelo Masarati wrote: > >> > >>>Did you compile with -DLDAP_DEPRECATED? > >> > >>I guess you're speaking of autofs here ? No, I did not. Should I try ? > > > > > > Yes. Just in case, as I cannot see a possible difference between > > OpenLDAP 2.2 and 2.3 up to there. The only noticeable thing that > > happens during ldap_init() is that global opts get copied into the LDAP > > handler. Unless the issue is over there (but it would have appeared > > ages ago...) > It works OK. It seems to imply all apps build against openldap should > define it, otherwise strange things may happen. Well, as I said, everything has worked fine so far on my x86_64 (but I don't use autofs); I had issues on Solaris 8 with 64 bit compiles, and I had to fix them accordingly. Typically these issues show up when explicit casts are used, because they don't allow compilers to issue warnings. In this specific case there seems to be little to do on the OpenLDAP side, because ldap_{s,g}et_option() interface heavily relies on explicit casts. Another approach would be to recommend apps developers to move to the non-deprecated APIs. However, I always find a lot of resistance when it comes to modify code that "ever worked so far". Do you think I can close this ITS? p. Ing. Pierangelo Masarati Responsabile Open Solution SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
Pierangelo Masarati wrote: >>It works OK. It seems to imply all apps build against openldap should >>define it, otherwise strange things may happen. > > > Well, as I said, everything has worked fine so far on my x86_64 (but I > don't use autofs); It worked fine also on previous mdv release, using openldap 2.2.23. > Another approach would be to recommend apps developers to move to the > non-deprecated APIs. However, I always find a lot of resistance when it > comes to modify code that "ever worked so far". I'll add it to my bugreport on autofs at bugzilla.kernel.org > Do you think I can close this ITS? Yes, many thanks for your help. -- Disks are always full. It is futile to try to get more disk space. Data expands to fill any void. -- Murphy's Computer Laws n°4
Em Segunda 14 Novembro 2005 20:25, você escreveu: > Another approach would be to recommend apps developers to move to the > non-deprecated APIs. However, I always find a lot of resistance when it > comes to modify code that "ever worked so far". Someone mentioned that openldap itself still uses the deprecated API someplaces.
On Tue, 2005-11-15 at 11:43 +0000, ahasenack@terra.com.br wrote: > Em Segunda 14 Novembro 2005 20:25, você escreveu: > > Another approach would be to recommend apps developers to move to the > > non-deprecated APIs. However, I always find a lot of resistance when it > > comes to modify code that "ever worked so far". > > Someone mentioned that openldap itself still uses the deprecated API > someplaces. That's (partly) correct. I recently singled out the last occurrences the compiler shows last night in HEAD; few remain in the tools, which I believe it's not a big issue right now, I'll take care of them ASAP compatibly to my time. If you find any, please feel free to file an ITS (patches are welcome, as usual). Unfortunately, not 100% can be replaced: for example, ldap_sort_values (3) and ldap_sort_entries(3) have no non-deprecated replacement, indicating that it's not OpenLDAP software's purpose to sort data the way end-users like, since there's no unique definition of sorting. However, we like to provide some sorting in ldapsearch(1), and the deprecated functions seem just fine for the purpose. p. Ing. Pierangelo Masarati Responsabile Open Solution SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
changed state Feedback to Closed
moved from Build to Archive.Build
64 bit; fixed by -DLDAP_DEPRECATED