gqclient-discuss Mailing List for GQ LDAP client (Page 38)

Bert Vermeulen wrote:
> 
> On Thu, 4 May 2000, Ross Golder wrote:
> 
> > Bert Vermeulen wrote:
> > >
> > > Argh! You're doing a release! Please wait just a little bit more, I'm
> > > working as fast as I can to update the site. Putting all kinds of links to
> > > sourceforge, etc. This will be done tonight. Who needs sleep, anyway?
> > >
> >
> > Sorry, I didn't realise. It's not critical that the site is up-to-date
> > (so many project homepages these days are not!), the main thing is that
> > people can download a recent tarball.
> 
> Yup, you're absolutely right.
> 
> I've uploaded the new site. It's so nice! The 0.2.3 tarball and RPM are
> online now.
> 

Perfect - it looks very good. If you don't mind me asking, what did you
use to generate the HTML and/or button images?

> Have you done a freshmeat announcement yet, or shall I?
> 

Yep, I posted it last night, and I've just checked - it's there.

--
Ross

On Fri, 28 Apr 2000, Ben Liblit wrote:

> GQ is a delightful tool.  But there is a small problem in the
> preferences dialog.  When one is using larger fonts, the labels of the
> two "View" checkboxes are cut off.
> 
> See the attached screen shot.  This was taken from a machine that is set
> up to use 100dpi fonts rather than the typical 75dpi fonts.  I believe
> that "-Adobe-Helvetica-Medium-R-Normal--17-120-100-100-P-88-ISO8859-1"
> is the actual font in use.

I can see from the screenshot what the problem is, but can't reproduce it
here, as I don't use those large fonts.

Can you tell me how you set up your environment to use those?


Bert Vermeulen
be...@bi...
--
Yes, I am an agent of Satan, but my duties are largely ceremonial.

On Wed, 3 May 2000 na...@dr... wrote:

> On  3 May, Bert Vermeulen wrote:
> > Well, there's a bunch of #ifdefs, so it should almost compile with openldap
> > 1.2.x libs. I think I forgot a couple of #ifdefs though, so it may not
> > compile out of the box. But you'd be missing out on a lot of really good
> > functionality.
> 
> some of my boxes don't use openldap. Mainly for testing compatibility
> testing but I still need/want gq on those boxes. 

Yes, of course. You can always compile against openldap in your homedir or
something (--with-ldap-prefix. Bit of a like a hassle maybe. Remember, you
only need to compile with the openldap libs, it will work against anything
resembling LDAP on the wire. Even yahoo.

> against an openldap 1.2.10 server it doesn't see the other suffixes.
> The old code didn't check the other values of the database attribute.
> See attached patch.

I think I fixed that at some point, or rather rewrote that entire function.  
Can you check if you still get this with GQ 0.2.3? It was released about 30
minutes ago :-)

> >> I'm also looking to improving browse mode on a large database (12000+
> >> entries, it's a test database for my nss_ldap2 and nss_ldap work)
> > 
> > It's slow, I know. I've never profiled that code, and I'm sure it could be
> > optimized, but I'm afraid the REALLY slow part of it is rendering -- GTK in
> > other words. But you're welcome to try, of course :-)
> 
> There are several things that can be done. One of the things I'm doing
> in nss_ldap2 is background population of the cache. It should be
> possible to do the same thing in gq, allowing background population of
> the tree.

Yes, good idea. But it's not going to change the fact that GTK+ trees render
very slowly if they have large datasets in them. Even a couple thousand
entries gets unbearably slow :-(

In any case, if you want to do this, the good news is that browse.c has a
level of abstraction you'll be wanting. It puts entries in a glib n-ary list
first, and only later converts the entire thing to a GTK+ tree.


Bert Vermeulen
be...@bi...
--
Yes, I am an agent of Satan, but my duties are largely ceremonial.

On Thu, 4 May 2000, Ross Golder wrote:

> Bert Vermeulen wrote:
> > 
> > Argh! You're doing a release! Please wait just a little bit more, I'm
> > working as fast as I can to update the site. Putting all kinds of links to
> > sourceforge, etc. This will be done tonight. Who needs sleep, anyway?
> > 
> 
> Sorry, I didn't realise. It's not critical that the site is up-to-date
> (so many project homepages these days are not!), the main thing is that
> people can download a recent tarball.

Yup, you're absolutely right.

I've uploaded the new site. It's so nice! The 0.2.3 tarball and RPM are
online now.

Have you done a freshmeat announcement yet, or shall I?


Bert Vermeulen
be...@bi...
--
Yes, I am an agent of Satan, but my duties are largely ceremonial.

Bert Vermeulen wrote:
> 
> Argh! You're doing a release! Please wait just a little bit more, I'm
> working as fast as I can to update the site. Putting all kinds of links to
> sourceforge, etc. This will be done tonight. Who needs sleep, anyway?
> 

Sorry, I didn't realise. It's not critical that the site is up-to-date
(so many project homepages these days are not!), the main thing is that
people can download a recent tarball.

> Does the 0.2.3 you packed up compile on stock 1.2.9 openldap?
> 

Yes, I did that today, and checked in the #ifdefs that I produced. I
have a nice clean RH62 machine at work, and it built just fine. Still,
knowing my luck someone out there will have problems! :)

Also, still builds fine on my machine at home, with CVS openldap.

Regards,

--
Ross

IBM:
	[International Business Machines Corp.]  Also known as Itty Bitty
	Machines or The Lawyer's Friend.  The dominant force in computer
	marketing, having supplied worldwide some 75% of all known hardware
	and 10% of all software.  To protect itself from the litigious envy
	of less successful organizations, such as the US government, IBM
	employs 68% of all known ex-Attorneys' General.

Bert Vermeulen wrote:
> 
> Before anything is announced, it should compile on an old (1.2.x) OpenLDAP,
> so people can at least use it. Unfortunately, without newer OpenLDAP
> versions, they won't see much difference from 0.2.2. Oh well.
> 

True, not much has changed since 0.2.2. The main thing is to start
getting releases out early and often to get more people interested in
testing and developing the code in different environments.

> If you can get that done, please prod me and I'll update biot.com instead. I
> know, I should do that anyway :-(
> 

Done. I uploaded stuff to
<ftp://." rel="nofollow">gqclient.sourceforge.net/pub/gqclient/>.

Regards,

--
Ross

na...@dr... wrote:
> 
> On  3 May, Bert Vermeulen wrote:
> > Well, there's a bunch of #ifdefs, so it should almost compile with openldap
> > 1.2.x libs. I think I forgot a couple of #ifdefs though, so it may not
> > compile out of the box. But you'd be missing out on a lot of really good
> > functionality.
> 

Must've missed this thread somehow. I checked in the #ifdefs today, when
I was trying to build against 1.2.9 on a standard RedHat 6.2 box.

Regards,

--
Ross

Argh! You're doing a release! Please wait just a little bit more, I'm
working as fast as I can to update the site. Putting all kinds of links to
sourceforge, etc. This will be done tonight. Who needs sleep, anyway?

Does the 0.2.3 you packed up compile on stock 1.2.9 openldap?



On Wed, 3 May 2000, Ross Golder wrote:

> Bert,
> 
> Hi. Hope you are well.
> 
> I've checked a couple of patches into CVS. One is a set of compiler
> directives that allow you to do a 'cvs co gqclient; cd gqclient;
> aclocal; autoconf; automake; ./configure; make dist; rpm -tb
> gq-0.2.3.tar.gz' on a clean RedHat 6.2 (w/RH-supplied openldap-1.2.9).
> The other is the inclusion of a GNOME menu entry. Oh, and I added the
> '-lresolv' patch for building against CVS openldap.
> 
> I've got my recent gq-0.2.3.tar.gz dist file, and a RH62-fresh
> gq-0.2.3.i386.rpm. At some point, I'm going to post them to the
> SourceForge webspace, and make an announcement on Freshmeat. Hopefully,
> that might drum up some testers and developers who might otherwise think
> the project had died. What do you think?
> 
> Regards,
> 
> --
> Ross
> 


Bert Vermeulen
be...@bi...
--
Yes, I am an agent of Satan, but my duties are largely ceremonial.

On Wed, 3 May 2000, Ross Golder wrote:

> Bert,
> 
> Hi. Hope you are well.
> 
> I've checked a couple of patches into CVS. One is a set of compiler
> directives that allow you to do a 'cvs co gqclient; cd gqclient;
> aclocal; autoconf; automake; ./configure; make dist; rpm -tb
> gq-0.2.3.tar.gz' on a clean RedHat 6.2 (w/RH-supplied openldap-1.2.9).
> The other is the inclusion of a GNOME menu entry. Oh, and I added the
> '-lresolv' patch for building against CVS openldap.

Great stuff!

> I've got my recent gq-0.2.3.tar.gz dist file, and a RH62-fresh
> gq-0.2.3.i386.rpm. At some point, I'm going to post them to the
> SourceForge webspace, and make an announcement on Freshmeat. Hopefully,
> that might drum up some testers and developers who might otherwise think
> the project had died. What do you think?

Yup, good idea. I've had lots of people mail and ask about GQ development
recently, so there's definitely a lot of interest.

Before anything is announced, it should compile on an old (1.2.x) OpenLDAP,
so people can at least use it. Unfortunately, without newer OpenLDAP
versions, they won't see much difference from 0.2.2. Oh well.

If you can get that done, please prod me and I'll update biot.com instead. I
know, I should do that anyway :-(


Bert Vermeulen
be...@bi...
--
Yes, I am an agent of Satan, but my duties are largely ceremonial.

On  3 May, Bert Vermeulen wrote:
> Well, there's a bunch of #ifdefs, so it should almost compile with openldap
> 1.2.x libs. I think I forgot a couple of #ifdefs though, so it may not
> compile out of the box. But you'd be missing out on a lot of really good
> functionality.

some of my boxes don't use openldap. Mainly for testing compatibility
testing but I still need/want gq on those boxes. 
 
>> > What changes have you made?
>> 
>> This main one was better handling of multiple suffixes in browse mode
>> (the code in 2.2 doesn't work).
> 
> Ermm... it works for me...

against an openldap 1.2.10 server it doesn't see the other suffixes.
The old code didn't check the other values of the database attribute.
See attached patch.
 
>> I'm also looking to improving browse mode on a large database (12000+
>> entries, it's a test database for my nss_ldap2 and nss_ldap work)
> 
> It's slow, I know. I've never profiled that code, and I'm sure it could be
> optimized, but I'm afraid the REALLY slow part of it is rendering -- GTK in
> other words. But you're welcome to try, of course :-)

There are several things that can be done. One of the things I'm doing
in nss_ldap2 is background population of the cache. It should be
possible to do the same thing in gq, allowing background population of
the tree.

-- 
Doug Nazar
Dragon Computer Consultants Inc.
Tel: (416) 708-1578     Fax: (416) 708-8081

Bert,

Hi. Hope you are well.

I've checked a couple of patches into CVS. One is a set of compiler
directives that allow you to do a 'cvs co gqclient; cd gqclient;
aclocal; autoconf; automake; ./configure; make dist; rpm -tb
gq-0.2.3.tar.gz' on a clean RedHat 6.2 (w/RH-supplied openldap-1.2.9).
The other is the inclusion of a GNOME menu entry. Oh, and I added the
'-lresolv' patch for building against CVS openldap.

I've got my recent gq-0.2.3.tar.gz dist file, and a RH62-fresh
gq-0.2.3.i386.rpm. At some point, I'm going to post them to the
SourceForge webspace, and make an announcement on Freshmeat. Hopefully,
that might drum up some testers and developers who might otherwise think
the project had died. What do you think?

Regards,

--
Ross

Bert Vermeulen wrote:
> 
> On Wed, 12 Apr 2000, Ross Golder wrote:
> 
> > configure:1320: checking for ldap_simple_bind in -lldap
> > configure:1339: gcc -o conftest -g -O2 -I/usr/lib/glib/include
> > -I/usr/X11R6/include  -I/usr/local/include  conftest.c -lldap -llber
> > -L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl
> > -lXi -lXext -lX11 -lm -L/usr/local/lib 1>&5
> > /usr/local/lib/libldap.so: undefined reference to `res_search'
> > /usr/local/lib/libldap.so: undefined reference to `dn_expand'
> > collect2: ld returned 1 exit status
> 
> This seems to be related to Luke Howard's DNS SRV patches to OpenLDAP.
> I didn't dig too deep, but deleting all references to dnssrv.c in
> libraries/libldap/Makefile keeps it from compiling that code in, and gives
> you a usable library.
> 

I noticed that 'res_search' and 'dn_expand' seem to be glibc calls, so I
added '-lresolv' to $LIBS in 'configure.in' and it worked fine.

Regards,

--
Ross

Ross Golder wrote:
> 
> Ross Golder wrote:
> >
> > I'm gonna try building it with ldap library compiled in statically, when
> > I get back from work.
> >
> 
> Added 'LDFLAGS = -static' to src/Makefile.am and ran it. OpenLDAP still
> looks dodgy:
> 

Re-checked out openldap and this appears to work now.

Regards,

--
Ross

Ross Golder wrote:
> 
> I'm gonna try building it with ldap library compiled in statically, when
> I get back from work.
> 

Added 'LDFLAGS = -static' to src/Makefile.am and ran it. OpenLDAP still
looks dodgy:

[rossg@durban src]$ gdb gq
GNU gdb 19991004
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
(gdb) run
Starting program: /public/workshop/gq/src/gq 
gdk_imlib ERROR: gdk has not connected to the display

Gdk-CRITICAL **: file gdkwindow.c: line 1406 (gdk_window_get_visual):
assertion `window != NULL' failed.

Gtk-CRITICAL **: file gtkwidget.c: line 4254 (gtk_widget_push_visual):
assertion `visual != NULL' failed.

Gtk-CRITICAL **: file gtkwidget.c: line 4238 (gtk_widget_push_colormap):
assertion `cmap != NULL' failed.

Program received signal SIGSEGV, Segmentation fault.
0x40084010 in ?? ()
(gdb) bt
#0  0x40084010 in ?? ()
#1  0x40083fba in ?? ()
#2  0x4032035d in ?? ()
#3  0x4031c263 in ?? ()
#4  0x4031bee8 in ?? ()
#5  0x40325b19 in ?? ()
#6  0x4019168b in ?? ()
#7  0x80a9854 in gtk_rc_parse_engine ()
#8  0x80a910a in gtk_rc_parse_style ()
#9  0x80a8d98 in gtk_rc_parse_statement ()
#10 0x80a869e in gtk_rc_parse_any ()
#11 0x80a7ccf in gtk_rc_parse_file ()
#12 0x80a8d8b in gtk_rc_parse_statement ()
#13 0x80a869e in gtk_rc_parse_any ()
#14 0x80a7ccf in gtk_rc_parse_file ()
#15 0x80a7d39 in gtk_rc_parse ()
#16 0x80a7b09 in gtk_rc_init ()
#17 0x808e619 in gtk_init_check ()
#18 0x808e690 in gtk_init ()
#19 0x80531e9 in main (argc=1, argv=0xbfffddf4) at gq.c:31
(gdb) 

--
Ross

IBM:
	[International Business Machines Corp.]  Also known as Itty Bitty
	Machines or The Lawyer's Friend.  The dominant force in computer
	marketing, having supplied worldwide some 75% of all known hardware
	and 10% of all software.  To protect itself from the litigious envy
	of less successful organizations, such as the US government, IBM
	employs 68% of all known ex-Attorneys' General.

Bert Vermeulen wrote:
> 
> On Fri, 14 Apr 2000, Ross Golder wrote:
> 
> > I can't run yet, as I'm getting:
> >
> > Starting program: /public/workshop/gq/src/gq
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x402773fe in ldap_int_put_controls (ld=0x80a9160, ctrls=0x0,
> 
> [...]
> 
> Looks like your nss_ldap isn't agreeing with openldap. Mine isn't either :(
> 

I'm gonna try building it with ldap library compiled in statically, when
I get back from work.

> That IS the better way. The alternative is to set LD_LIBRARY_PATH.

That's what I was trying to think of. You don't need to keep 'su'ing to
root and running ldconfig with that one.

Regards,

--
Ross

IBM:
	[International Business Machines Corp.]  Also known as Itty Bitty
	Machines or The Lawyer's Friend.  The dominant force in computer
	marketing, having supplied worldwide some 75% of all known hardware
	and 10% of all software.  To protect itself from the litigious envy
	of less successful organizations, such as the US government, IBM
	employs 68% of all known ex-Attorneys' General.

On Fri, 14 Apr 2000, Ross Golder wrote:

> I can't run yet, as I'm getting:
> 
> Starting program: /public/workshop/gq/src/gq 
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x402773fe in ldap_int_put_controls (ld=0x80a9160, ctrls=0x0,

[...]

Looks like your nss_ldap isn't agreeing with openldap. Mine isn't either :(

> BTW, do you know if there is a better way to get ld.so to also look in
> /usr/local/lib for libraries than add it to /etc/ld.so.conf?

That IS the better way. The alternative is to set LD_LIBRARY_PATH.



Bert Vermeulen
be...@bi...
--
Yes, I am an agent of Satan, but my duties are largely ceremonial.

Bert Vermeulen wrote:
> 
> On Wed, 12 Apr 2000, Ross Golder wrote:
> 
> > configure:1320: checking for ldap_simple_bind in -lldap
> > configure:1339: gcc -o conftest -g -O2 -I/usr/lib/glib/include
> > -I/usr/X11R6/include  -I/usr/local/include  conftest.c -lldap -llber
> > -L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl
> > -lXi -lXext -lX11 -lm -L/usr/local/lib 1>&5
> > /usr/local/lib/libldap.so: undefined reference to `res_search'
> > /usr/local/lib/libldap.so: undefined reference to `dn_expand'
> > collect2: ld returned 1 exit status
> 
> This seems to be related to Luke Howard's DNS SRV patches to OpenLDAP.
> I didn't dig too deep, but deleting all references to dnssrv.c in
> libraries/libldap/Makefile keeps it from compiling that code in, and gives
> you a usable library.
> 

Cool. I can build now (with a few small mods to configure.in and
Makefile.am, which I've committed).

I can't run yet, as I'm getting:

Starting program: /public/workshop/gq/src/gq 

Program received signal SIGSEGV, Segmentation fault.
0x402773fe in ldap_int_put_controls (ld=0x80a9160, ctrls=0x0,
ber=0x80a9560)
    at controls.c:48
48		if( ctrls == NULL || *ctrls == NULL ) {
(gdb) bt
#0  0x402773fe in ldap_int_put_controls (ld=0x80a9160, ctrls=0x0, 
    ber=0x80a9560) at controls.c:48
#1  0x40276871 in ldap_build_search_req (ld=0x80a9160, 
    base=0x403d238b "dc=rossg,dc=home,dc=lan", scope=2, 
    filter_in=0xbfffd78c "(&(objectclass=posixAccount)(uidNumber=500))", 
    attrs=0x403d18d8, attrsonly=0, sctrls=0x0, cctrls=0x0, timelimit=-1, 
    sizelimit=-1) at search.c:327
#2  0x402766ed in ldap_search (ld=0x80a9160, 
    base=0x403d238b "dc=rossg,dc=home,dc=lan", scope=2, 
    filter=0xbfffd78c "(&(objectclass=posixAccount)(uidNumber=500))", 
    attrs=0x403d18d8, attrsonly=0) at search.c:207
#3  0x403c2fbc in do_search () from /lib/libnss_ldap.so.2
#4  0x403c2e1d in do_with_reconnect () from /lib/libnss_ldap.so.2
#5  0x403c32bc in _nss_ldap_search () from /lib/libnss_ldap.so.2
#6  0x403c33e4 in _nss_ldap_getbyname () from /lib/libnss_ldap.so.2
#7  0x403c3b55 in _nss_ldap_getpwuid_r () from /lib/libnss_ldap.so.2
#8  0x4032947b in __getpwuid_r (uid=500, resbuf=0xbfffdc7c, 
    buffer=0x80a1db0 "gdm", buflen=64, result=0xbfffdc78)
    at ../nss/getXXbyYY_r.c:182
#9  0x4018f185 in g_get_any_init () from /usr/lib/libglib-1.2.so.0
#10 0x4018f49d in g_get_home_dir () from /usr/lib/libglib-1.2.so.0
#11 0x400cac63 in gtk_rc_append_default_module_path ()
   from /usr/lib/libgtk-1.2.so.0
---Type <return> to continue, or q <return> to quit--- 
#12 0x400cb0d6 in gtk_rc_init () from /usr/lib/libgtk-1.2.so.0
#13 0x400a7409 in gtk_init_check () from /usr/lib/libgtk-1.2.so.0
#14 0x400a748d in gtk_init () from /usr/lib/libgtk-1.2.so.0
#15 0x805a769 in main (argc=1, argv=0xbfffdda4) at gq.c:31
(gdb)  

:(( - I'll have to look into it over the weekend.

BTW, do you know if there is a better way to get ld.so to also look in
/usr/local/lib for libraries than add it to /etc/ld.so.conf?

Cheers,

--
Ross

IBM:
	[International Business Machines Corp.]  Also known as Itty Bitty
	Machines or The Lawyer's Friend.  The dominant force in computer
	marketing, having supplied worldwide some 75% of all known hardware
	and 10% of all software.  To protect itself from the litigious envy
	of less successful organizations, such as the US government, IBM
	employs 68% of all known ex-Attorneys' General.

On Wed, 12 Apr 2000, Ross Golder wrote:

> configure:1320: checking for ldap_simple_bind in -lldap
> configure:1339: gcc -o conftest -g -O2 -I/usr/lib/glib/include
> -I/usr/X11R6/include  -I/usr/local/include  conftest.c -lldap -llber 
> -L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl
> -lXi -lXext -lX11 -lm -L/usr/local/lib 1>&5
> /usr/local/lib/libldap.so: undefined reference to `res_search'
> /usr/local/lib/libldap.so: undefined reference to `dn_expand'
> collect2: ld returned 1 exit status

This seems to be related to Luke Howard's DNS SRV patches to OpenLDAP.
I didn't dig too deep, but deleting all references to dnssrv.c in
libraries/libldap/Makefile keeps it from compiling that code in, and gives
you a usable library.


Bert Vermeulen
be...@bi...
--
Yes, I am an agent of Satan, but my duties are largely ceremonial.

Bert Vermeulen wrote:
> 
> Er well, one I checked out quite a while back. I've since ditched it and
> checked out again, and I'm getting the same error :(
> 
> I don't expect it's going to be anything major, probably easily fixed. Time
> as usual is short, though. Being on holiday doesn't seem to make any
> difference, somehow!
> 
> You may be amused to know it killed my nss_ldap, too :-P
> 

Hehe! Life on the bleeding edge can be such fun ;)

I've got an hour to kill before I meet a friend. I'll have a look into
it and maybe raise a report to the openldap crew.

Regards,

--
Ross

P-p-p-pick up a penguin.

On Wed, 12 Apr 2000, Ross Golder wrote:

> Thanks. Got that bit working. Next problem - looks like latest CVS
> version of openldap is broken, if I'm understanding the error messages
> correctly:
> 
> configure:1320: checking for ldap_simple_bind in -lldap
> configure:1339: gcc -o conftest -g -O2 -I/usr/lib/glib/include
> -I/usr/X11R6/include  -I/usr/local/include  conftest.c -lldap -llber 
> -L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl
> -lXi -lXext -lX11 -lm -L/usr/local/lib 1>&5
> /usr/local/lib/libldap.so: undefined reference to `res_search'
> /usr/local/lib/libldap.so: undefined reference to `dn_expand'
> collect2: ld returned 1 exit status
> 
> What date was the CVS checkout that you're working with?

Er well, one I checked out quite a while back. I've since ditched it and
checked out again, and I'm getting the same error :(

I don't expect it's going to be anything major, probably easily fixed. Time
as usual is short, though. Being on holiday doesn't seem to make any
difference, somehow!

You may be amused to know it killed my nss_ldap, too :-P


Bert Vermeulen
be...@bi...
--
Yes, I am an agent of Satan, but my duties are largely ceremonial.

Bert Vermeulen wrote:
> 
> > Guess I'll have to keep cracking on getting the latest CVS version of
> > openldap working. Unfortunately, I am using nss_ldap package on my
> > workstation, so if I break libldap/liblber, it won't know who I am! I'll
> > get there soon.
> 
> That doesn't have to be a problem -- you can compile against an LDAP install
> in another directory, use the --with-ldap-prefix option to configure. You
> can then at least connect to some LDAP V3 server out on the net.
> 

Thanks. Got that bit working. Next problem - looks like latest CVS
version of openldap is broken, if I'm understanding the error messages
correctly:

configure:1320: checking for ldap_simple_bind in -lldap
configure:1339: gcc -o conftest -g -O2 -I/usr/lib/glib/include
-I/usr/X11R6/include  -I/usr/local/include  conftest.c -lldap -llber 
-L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl
-lXi -lXext -lX11 -lm -L/usr/local/lib 1>&5
/usr/local/lib/libldap.so: undefined reference to `res_search'
/usr/local/lib/libldap.so: undefined reference to `dn_expand'
collect2: ld returned 1 exit status

What date was the CVS checkout that you're working with?

TIA,

--
Ross

P-p-p-pick up a penguin.

On Sun, 9 Apr 2000, Ross Golder wrote:

> I've uploaded a modified specfile patch, so users can do the 'rpm -tb'
> thing.

Good stuff!

> Still having problems building the damn thing:
> 
> gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -I/usr/lib/glib/include
> -I/usr/X11R6/include -Wall -c tinput.c
> tinput.c:24: ldap_schema.h: No such file or directory

ldap_schema.h isn't there in OpenLDAP 1.x, it holds the structs etc for the
new LDAP V3 schema functions.

> Guess I'll have to keep cracking on getting the latest CVS version of
> openldap working. Unfortunately, I am using nss_ldap package on my
> workstation, so if I break libldap/liblber, it won't know who I am! I'll
> get there soon.

That doesn't have to be a problem -- you can compile against an LDAP install
in another directory, use the --with-ldap-prefix option to configure. You
can then at least connect to some LDAP V3 server out on the net.


Bert Vermeulen
be...@bi...
--
Yes, I am an agent of Satan, but my duties are largely ceremonial.

Hello to the thousands of subscribers to this list. In other words,
'Hello Bert!'.

I see you've shifted the source into a subdir. Good idea.

I've uploaded a modified specfile patch, so users can do the 'rpm -tb'
thing.

Still having problems building the damn thing:

gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -I/usr/lib/glib/include
-I/usr/X11R6/include -Wall -c tinput.c
tinput.c:24: ldap_schema.h: No such file or directory

Guess I'll have to keep cracking on getting the latest CVS version of
openldap working. Unfortunately, I am using nss_ldap package on my
workstation, so if I break libldap/liblber, it won't know who I am! I'll
get there soon.

TTFN,

--
Ross