Re: gnome-libs and DB3

[Matthew Schalit <mschalit pacbell net>]

Drazen Kacar wrote:
> 
> Matthew Schalit wrote:
> 
> > Ok.  I tried 3.2.9 and I can get it to ouput a __db185_open like you
> > mentioned.
> >
> > Given that fact, it appears that it would pass the current gnome-libs
> > configure conftest.  I don't know whether it would work in practice
> > though, because, as I mentioned, any version above 2.7.7 breaks db185
> > compatability due to the removal of functions like dbopen().
> 
> I don't know, because I havent tried. I intend to (try to) build Gnome
> with BDB 3 after 1.4 release. If dbopen() is really needed and if it
> does the same thing as __db_open() (more or less), then there is
> assortment of sed jobs, linker options and other magick available.
> Something depends on the platform, but not everything.


I'm getting it now.  My main problem was getting any __db185_open at all.
Now that that's fixed, I might try it myself.  My whole Gnome setup doesn't
really work too well with Enlightenment 16.5, all done with gcc 2.95.2.1,
and gnu-make 3.79.1 because of MIT-SHM X Shared Memory problems, but that's
probably due to my running the stock X11, not XFree86.


 
> > ones BDB included.   No luck there.  I get a dynamic linker error complaining
> > symbol not found: cond_signal; referenced from: .libs/libdb_tcl-3.2.so
> 
> That's a function from UI thread package. I'm not sure in which library
> you have it (on Solaris it's in libthread.so.1, so it might be the same).
> Check the man page and find the library. Then check if libdb_tcl-3.2.so
> is linked with that library. If not, force the inclusion when linking.



Thanks for the heads up.  On UnixWare 7.1.1 with gcc, we use -pthread
as one of the LIBS to the Makefile command to get thread support.  Gcc does
the magic to get pthreads into the mix when it sees that.  

The configure program section that searchs for threads worked fine on 3.1.17, 
but they changed something here and I'm getting these errors.  I'll try to 
tweak it a bit and see what I can crowbar in.  I know it wanted to use -lthread, 
but I messed with it :)


 
> That should allow you to pass the test, but I'm not sure if the whole
> thing would actually work in practice. If you have a single threaded
> application which is linked with the library that brings thread library
> into process space, anything's possible. Unless the platform documents
> what happens in that case.
> 
> BTW, which compiler did you use?


gcc 2.95.2.1.

 
> > So if I can't test 3.2.9 and the readme says to use 2.7.7, then I figure
> > it's best for me to use 2.7.7.
> 
> Oh, I'm not arguing against that, but I'd like to have working
> installation with BDB 3, in order to avoid having several of them around
> and possible upgrade nightmares. So I'd like to invest some time in making
> it work with version 3, but this is purely a personal preference.


I'd certainly be happier with > 3.1.17, seeing as Sleepycat told me that
we had a totally functioning BDB based on the testsuite reports I emailed
to them.

Take it easy,
Matthew