A fresh pull (as of 2 minutes ago) builds fine for me.
If the problem you're running into is that distclean left something from
your previous build, then you need to tell us what your previous build
invocation was as well.
I suggest you try building with a separate object directory, so that you
can just rm -rf the object tree when you want a fresh build. e.g.
mkdir head
cd head
cvs co ...
cd ..
mkdir obj
cd obj
../head/configure ...
make depend; make
Personally I have never used "make distclean" ...
michael(a)stroeder.com wrote:
> Full_Name: Michael Ströder
> Version: HEAD
> OS: SuSE Linux 10.1
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (83.124.30.198)
>
>
> I tried to build without modules (after make distclean):
>
> ./configure \
> --prefix=${PREFIX} \
> --enable-dynamic \
> --enable-modules=no \
> --enable-backends=yes \
> --enable-overlays=yes \
> --enable-cleartext \
> --enable-crypt=yes \
> --enable-debug=yes \
> --enable-kpasswd=yes \
> --enable-lmpasswd=yes \
> --enable-rewrite=yes \
> --enable-rlookups=yes \
> --enable-slapi=yes \
> --enable-slp=yes \
> --enable-spasswd=yes \
> --enable-wrappers=no \
> --enable-aci=yes \
> --with-cyrus-sasl=yes \
> --with-kerberos=yes \
> --with-readline=yes \
> --with-threads=yes \
> --with-tls=yes
>
>
> But build fails:
>
> cc -g -O0 -I../../../include -I../../../include -I.. -I./.. -I./../slapi
> -I/opt/bdb-4.5/include -I/opt/sasl/include -I/opt/heimdal/include -c version.c
> -o version.o
> ar ruv libback_monitor.a `echo init.lo search.lo compare.lo modify.lo bind.lo
> operational.lo cache.lo entry.lo backend.lo database.lo thread.lo conn.lo rww.lo
> log.lo operation.lo sent.lo listener.lo time.lo overlay.lo | sed 's/\.lo/.o/g'`
> version.o
> ar: creating libback_monitor.a
> ar: init.o: No such file or directory
> make[3]: *** [libback_monitor.a] Error 1
> make[3]: Leaving directory
> `/home/michael/src/openldap-HEAD/ldap/servers/slapd/back-monitor'
> make[2]: *** [.backend] Error 1
> make[2]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/servers/slapd'
> make[1]: *** [all-common] Error 1
> make[1]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/servers'
> make: *** [all-common] Error 1
>
>
>
>
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
Hi,
On Thursday, 2. November 2006 20:42, Quanah Gibson-Mount wrote:
> Peter S, Dave, Peter M, Frank, and Todd, do you also grant such a release
> for the work you've done with this script? :)
Granted !
Peter
--
Peter Marschall
peter(a)adpm.de
> This overlay provides simple support for allowedAttributes and
> allowedAttributesEffective, a (somewhat broken) AD feature that is
> intended to
> help GUIs into determining, based on the current objectClass values of an
> object, what attributes would comply with the schema (without distinction
> between "allowed" and "required"), by listing them in "allowedAttributes",
This could be made more useful by providing ";x-allowed" or ";x-required"
options to "allowedAttributes", so that GUI developers can easily handle
mandatory vs. optional fields. However, I bet this would break existing
applications that make use of those attributes.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
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(a)sys-net.it
------------------------------------------
Full_Name: Pierangelo Masarati
Version: HEAD
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/pierangelo-masarati-2006-11-03-allowed.c
Submission from: (NULL) (81.72.89.40)
Submitted by: ando
This overlay provides simple support for allowedAttributes and
allowedAttributesEffective, a (somewhat broken) AD feature that is intended to
help GUIs into determining, based on the current objectClass values of an
object, what attributes would comply with the schema (without distinction
between "allowed" and "required"), by listing them in "allowedAttributes", and,
furthermore, by providing a hint to what of those values could be effectively
added by the current connection, by listing them in
"allowedAttributesEffective". This is broken since it doesn't consider the
possibility of value-dependent ACLs, so it should really be considered just a
hint, while the "allowedAttributes" could really be computed starting from the
schema definition, which remains the recommended way to solve the problem
So this overlay should really be considered only food for thought as a starting
base for a tighter integration of OpenLDAP into Samba4.
There's minimal support for "allowedChildClasses" and
"allowedChildClassesEffective", whose definition is absolutely obscure to me, as
I believe the only classes that can be added to an existing object are all the
AUXILIARY ones, while considering what are effectively allowed implies getting
into value-dependent ACLs.
Some discussion can be found here (follow the thread)
<http://www.redhat.com/archives/fedora-directory-devel/2006-November/msg0000…>
while portions of the schema definition has been taken from here
<http://www.redhat.com/archives/fedora-directory-devel/2006-August/msg00007.…>
p.
--On Thursday, November 02, 2006 11:07 PM +0000 ghenry(a)suretecsystems.com
wrote:
> <quote who="quanah(a)stanford.edu">
>> I'd like to see this script included as well. There were two concern
>> listed in the ITS:
>>
>> # 1) Awaiting new version with proper copyright notice.
>> # 2) Need information about incorporated patches to ensure all who have
>> # IPR
>> in this
>> script have made appropriate license grants.
>>
>> I know #1 has been addressed.
>>
>> As for #2, I grant such a release for the work I've done on the script.
>>
>> Peter S, Dave, Peter M, Frank, and Todd, do you also grant such a release
>> for the work you've done with this script? :)
>
> Do you mind if I do some clean up on it?
>
> Mainly Perl::Critic and Perl::Tidy. There's a few tests missing and
> assumptions been made with opening files and system commands etc.
>
> I'll have a patch tomorrow.
>
> You can take it or leave it ;-)
I don't mind at all, just make sure you get the very latest version. ;)
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
<quote who="quanah(a)stanford.edu">
> I'd like to see this script included as well. There were two concern
> listed in the ITS:
>
> #1) Awaiting new version with proper copyright notice.
> #2) Need information about incorporated patches to ensure all who have IPR
> in this
> script have made appropriate license grants.
>
> I know #1 has been addressed.
>
> As for #2, I grant such a release for the work I've done on the script.
>
> Peter S, Dave, Peter M, Frank, and Todd, do you also grant such a release
> for the work you've done with this script? :)
Do you mind if I do some clean up on it?
Mainly Perl::Critic and Perl::Tidy. There's a few tests missing and
assumptions been made with opening files and system commands etc.
I'll have a patch tomorrow.
You can take it or leave it ;-)
Gavin.
http://perlmonks.org/?node_id=386673http://www.suretecsystems.com/