michael@stroeder.com wrote:
> Full_Name: 
> Version: HEAD
> OS: Linux
> URL: 
> Submission from: (NULL) (84.163.96.140)
>
>
> cc -g -O2 -Wl,-R/dummy/lib -Wl,-R/dummy/lib -Wl,-R/dummy/lib -Wl,-R/dummy/lib -o
> .libs/ldapurl ldapurl.o lduversion.o  -L/dummy/lib
> ../../libraries/liblutil/liblutil.a ../../libraries/libldap/.libs/libldap.so
> /usr/src/michael/openldap/HEAD/openldap/libraries/liblber/.libs/liblber.so
> ../../libraries/liblber/.libs/liblber.so -lsasl2 -lssl -lcrypto -lcrypt -lresolv
> -Wl,--rpath -Wl,/opt/openldap-HEAD/lib
> ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_getline'
> ../../libraries/libldap/.libs/libldap.so: undefined reference to
> `ldif_countlines'
> ../../libraries/libldap/.libs/libldap.so: undefined reference to
> `ldif_parse_line2'
> ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_debug'
> collect2: ld returned 1 exit status
> make[2]: *** [ldapurl] Error 1
> make[2]: Leaving directory
> `/usr/src/michael/openldap/HEAD/openldap/clients/tools'
> make[1]: *** [all-common] Error 1
> make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/clients'
> make: *** [all-common] Error 1
>
>   
This is most likely related to my recent LDIF changes.  But I didn't see 
this problem.  What platform is this?  What build flags are you using?

richm@stanfordalumni.org wrote:
> michael@stroeder.com wrote:
>> Full_Name:
>> Version: HEAD
>> OS: Linux
>> URL:
>> Submission from: (NULL) (84.163.96.140)
>>
>>
>> cc -g -O2 -Wl,-R/dummy/lib -Wl,-R/dummy/lib -Wl,-R/dummy/lib -Wl,-R/dummy/lib -o
>> .libs/ldapurl ldapurl.o lduversion.o  -L/dummy/lib
>> ../../libraries/liblutil/liblutil.a ../../libraries/libldap/.libs/libldap.so
>> /usr/src/michael/openldap/HEAD/openldap/libraries/liblber/.libs/liblber.so
>> ../../libraries/liblber/.libs/liblber.so -lsasl2 -lssl -lcrypto -lcrypt -lresolv
>> -Wl,--rpath -Wl,/opt/openldap-HEAD/lib
>> ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_getline'
>> ../../libraries/libldap/.libs/libldap.so: undefined reference to
>> `ldif_countlines'
>> ../../libraries/libldap/.libs/libldap.so: undefined reference to
>> `ldif_parse_line2'
>> ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_debug'
>> collect2: ld returned 1 exit status
>> make[2]: *** [ldapurl] Error 1
>> make[2]: Leaving directory
>> `/usr/src/michael/openldap/HEAD/openldap/clients/tools'
>> make[1]: *** [all-common] Error 1
>> make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/clients'
>> make: *** [all-common] Error 1
>>
>>
> This is most likely related to my recent LDIF changes.  But I didn't see
> this problem.  What platform is this?  What build flags are you using?

Built fine here too, looks like an inconsistent build tree over there.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

hyc@symas.com wrote:
> richm@stanfordalumni.org wrote:
>> michael@stroeder.com wrote:
>>> Full_Name:
>>> Version: HEAD
>>> OS: Linux
>>> URL:
>>> Submission from: (NULL) (84.163.96.140)
>>>
>>>
>>> cc -g -O2 -Wl,-R/dummy/lib -Wl,-R/dummy/lib -Wl,-R/dummy/lib -Wl,-R/dummy/lib -o
>>> .libs/ldapurl ldapurl.o lduversion.o  -L/dummy/lib
>>> ../../libraries/liblutil/liblutil.a ../../libraries/libldap/.libs/libldap.so
>>> /usr/src/michael/openldap/HEAD/openldap/libraries/liblber/.libs/liblber.so
>>> ../../libraries/liblber/.libs/liblber.so -lsasl2 -lssl -lcrypto -lcrypt -lresolv
>>> -Wl,--rpath -Wl,/opt/openldap-HEAD/lib
>>> ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_getline'
>>> ../../libraries/libldap/.libs/libldap.so: undefined reference to
>>> `ldif_countlines'
>>> ../../libraries/libldap/.libs/libldap.so: undefined reference to
>>> `ldif_parse_line2'
>>> ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_debug'
>>> collect2: ld returned 1 exit status
>>> make[2]: *** [ldapurl] Error 1
>>> make[2]: Leaving directory
>>> `/usr/src/michael/openldap/HEAD/openldap/clients/tools'
>>> make[1]: *** [all-common] Error 1
>>> make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/clients'
>>> make: *** [all-common] Error 1
>>>
>>>
>> This is most likely related to my recent LDIF changes.  But I didn't see
>> this problem.  What platform is this?  What build flags are you using?
> 
> Built fine here too, looks like an inconsistent build tree over there.

The build with the same build flags on the very same system worked right
before the recent libldif check-ins. I'm using anon CVS pserver for cvs up.

Ciao, Michael.

Michael Ströder wrote:
> hyc@symas.com wrote:
>> richm@stanfordalumni.org wrote:
>>> This is most likely related to my recent LDIF changes.  But I didn't see
>>> this problem.  What platform is this?  What build flags are you using?
>>
>> Built fine here too, looks like an inconsistent build tree over there.
>
> The build with the same build flags on the very same system worked right
> before the recent libldif check-ins. I'm using anon CVS pserver for cvs up.

The anon CVS server has some lag in receiving updates from the master server. 
Don't you have an account on the master?

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

changed notes
changed state Open to Test
moved from Incoming to Build

changed notes

> Michael Ströder wrote:
>> hyc@symas.com wrote:
>>> richm@stanfordalumni.org wrote:
>>>> This is most likely related to my recent LDIF changes.  But I didn't
>>>> see
>>>> this problem.  What platform is this?  What build flags are you using?
>>>
>>> Built fine here too, looks like an inconsistent build tree over there.
>>
>> The build with the same build flags on the very same system worked right
>> before the recent libldif check-ins. I'm using anon CVS pserver for cvs
>> up.
>
> The anon CVS server has some lag in receiving updates from the master
> server.
> Don't you have an account on the master?

Actually it's not that; Michael routinely builds with --enable-dynamic,
and libldap now (dynamically) depends on liblutil for the LDIF part.

p.

masarati@aero.polimi.it wrote:
>> Michael Ströder wrote:
>>     
>>> hyc@symas.com wrote:
>>>       
>>>> richm@stanfordalumni.org wrote:
>>>>         
>>>>> This is most likely related to my recent LDIF changes.  But I didn't
>>>>> see
>>>>> this problem.  What platform is this?  What build flags are you using?
>>>>>           
>>>> Built fine here too, looks like an inconsistent build tree over there.
>>>>         
>>> The build with the same build flags on the very same system worked right
>>> before the recent libldif check-ins. I'm using anon CVS pserver for cvs
>>> up.
>>>       
>> The anon CVS server has some lag in receiving updates from the master
>> server.
>> Don't you have an account on the master?
>>     
>
> Actually it's not that; Michael routinely builds with --enable-dynamic,
> and libldap now (dynamically) depends on liblutil for the LDIF part.
>   
I did not want to introduce any new dependencies nor break any existing 
code with the new LDIF library.  Ideally, you would only have to link 
with -lldif for external code that wants to use the LDIF API (such as 
ldif_get_entry or ldif_parse_line).  Any existing code, or code that 
just wants to use the new higher level api ldap_parse_ldif_record_x 
would only have to link with -lldap.

Is --enable-dynamic the only additional build flag I need to use?
> p.
>
>
>
>
>
>   

> masarati@aero.polimi.it wrote:

>> Actually it's not that; Michael routinely builds with --enable-dynamic,
>> and libldap now (dynamically) depends on liblutil for the LDIF part.
>>
> I did not want to introduce any new dependencies nor break any existing
> code with the new LDIF library.  Ideally, you would only have to link
> with -lldif for external code that wants to use the LDIF API (such as
> ldif_get_entry or ldif_parse_line).  Any existing code, or code that
> just wants to use the new higher level api ldap_parse_ldif_record_x
> would only have to link with -lldap.
>
> Is --enable-dynamic the only additional build flag I need to use?

In fact, you did not introduce any further dependence, as ldif_* functions
(those provided in liblutil/ldif.c) are present in liblutil.  I fixed the
issue by reversing the link order of libraries.

It used to be liblutil, liblber, libldap (I think that was because earlier
there used to be dependencies of liblutil on the others, please correct
me). Now it's libldap, liblber, liblutil, and it builds fine with
--enable-dynamic=yes/no.  Please check whether my fix is appropriate.

p.

masarati@aero.polimi.it wrote:
>> masarati@aero.polimi.it wrote:
>>     
>
>   
>>> Actually it's not that; Michael routinely builds with --enable-dynamic,
>>> and libldap now (dynamically) depends on liblutil for the LDIF part.
>>>
>>>       
>> I did not want to introduce any new dependencies nor break any existing
>> code with the new LDIF library.  Ideally, you would only have to link
>> with -lldif for external code that wants to use the LDIF API (such as
>> ldif_get_entry or ldif_parse_line).  Any existing code, or code that
>> just wants to use the new higher level api ldap_parse_ldif_record_x
>> would only have to link with -lldap.
>>
>> Is --enable-dynamic the only additional build flag I need to use?
>>     
>
> In fact, you did not introduce any further dependence, as ldif_* functions
> (those provided in liblutil/ldif.c) are present in liblutil.  I fixed the
> issue by reversing the link order of libraries.
>
> It used to be liblutil, liblber, libldap (I think that was because earlier
> there used to be dependencies of liblutil on the others, please correct
> me). Now it's libldap, liblber, liblutil, and it builds fine with
> --enable-dynamic=yes/no.  Please check whether my fix is appropriate.
>   
I just pulled the latest code from anonymous@cvs.openldap.org - started 
from a clean directory - ran configure with --enable-dynamic 
--disable-static - make depend and make install - build completed 
successfully - server works fine, ldapmodify works fine
> p.
>
>
>
>
>   

masarati@aero.polimi.it wrote:
>> masarati@aero.polimi.it wrote:
> 
>>> Actually it's not that; Michael routinely builds with --enable-dynamic,
>>> and libldap now (dynamically) depends on liblutil for the LDIF part.
>>>
>> I did not want to introduce any new dependencies nor break any existing
>> code with the new LDIF library.  Ideally, you would only have to link
>> with -lldif for external code that wants to use the LDIF API (such as
>> ldif_get_entry or ldif_parse_line).  Any existing code, or code that
>> just wants to use the new higher level api ldap_parse_ldif_record_x
>> would only have to link with -lldap.
>>
>> Is --enable-dynamic the only additional build flag I need to use?
> 
> In fact, you did not introduce any further dependence, as ldif_* functions
> (those provided in liblutil/ldif.c) are present in liblutil.  I fixed the
> issue by reversing the link order of libraries.
> 
> It used to be liblutil, liblber, libldap (I think that was because earlier
> there used to be dependencies of liblutil on the others, please correct
> me). Now it's libldap, liblber, liblutil, and it builds fine with
> --enable-dynamic=yes/no.  Please check whether my fix is appropriate.

It seems to work for me now.

Ciao, Michael.

changed state Test to Closed

changed notes
changed state Closed to Test

Using these instructions, the issue remains with current CVS:

I have had it sometimes build from an old tree, but this from scratch
does not:

==Getting OpenLDAP==
This guide presumes you are running OpenLDAP CVS HEAD from after 22
April 2010 (or a release after that date)

You need the 'deref' and 'rdnval' overlay.  This may be in your packaged
version, but if not your must rebuild.

To get OpenLDAP from CVS run:

 CVSROOT=:pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP
 export CVSROOT
 cvs login

You will need to enter at the prompt:
 Password: (enter OpenLDAP)

Then check out the tree
 cvs -z3 checkout -P openldap

Then change to the newly created 'openldap' directory:
 cd openldap

To update your OpenLDAP checkout (discarding local conflicts) from CVS
run:

 cvs -z9 update -dP 2>&1 | grep ^C | cut -b3-| xargs rm
 cvs -z9 update -dP

To build it run:

 CFLAGS="-fno-omit-frame-pointer" `dirname $0`/configure
--enable-overlays=mod --enable-modules --enable-dynamic || exit 1
 make clean all AC_CFLAGS=-g

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

>
> --=-hLLTpGMzur3nD+xeX+/o
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> Using these instructions, the issue remains with current CVS:

Should be (re-)fixed in HEAD (pull out libraries/librewrite/Makefile.in). 
The issue emerged when ldifutil.c (who pulls in ldif_* from liblutil) was
also added to libldap_r; this broke librewrite.  It happened after
ITS#6517 was closed.  Please test.  Thanks, p.

> I have had it sometimes build from an old tree, but this from scratch
> does not:
>
> =3D=3DGetting OpenLDAP=3D=3D
> This guide presumes you are running OpenLDAP CVS HEAD from after 22
> April 2010 (or a release after that date)
>
> You need the 'deref' and 'rdnval' overlay.  This may be in your packaged
> version, but if not your must rebuild.
>
> To get OpenLDAP from CVS run:
>
>  CVSROOT=3D:pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP
>  export CVSROOT
>  cvs login
>
> You will need to enter at the prompt:
>  Password: (enter OpenLDAP)
>
> Then check out the tree
>  cvs -z3 checkout -P openldap
>
> Then change to the newly created 'openldap' directory:
>  cd openldap
>
> To update your OpenLDAP checkout (discarding local conflicts) from CVS
> run:
>
>  cvs -z9 update -dP 2>&1 | grep ^C | cut -b3-| xargs rm
>  cvs -z9 update -dP
>
> To build it run:
>
>  CFLAGS=3D"-fno-omit-frame-pointer" `dirname $0`/configure
> --enable-overlays=3Dmod --enable-modules --enable-dynamic || exit 1
>  make clean all AC_CFLAGS=3D-g
>
> --=20
> Andrew Bartlett                                http://samba.org/~abartlet/
> Authentication Developer, Samba Team           http://samba.org
> Samba Developer, Cisco Inc.
>
>
> --=-hLLTpGMzur3nD+xeX+/o
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: This is a digitally signed message part
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
>
> iD8DBQBL0BYkz4A8Wyi0NrsRAuntAKCf7rc4Q9IQrpMwcTeY6cOQIaSgnQCeOGh2
> FxErm+tMjQUnb0y7Hmgs9n8=
> =zuyi
> -----END PGP SIGNATURE-----
>
> --=-hLLTpGMzur3nD+xeX+/o--
>
>
>
>

changed notes
changed state Test to Closed

fixed in HEAD; HEAD only
re-opened after fix to librewrite/Makefile.in