Re: Berkeley DB : Solaris : gnome-libs

[Drazen Kacar <dave srce hr>]

Miroslav Silovic wrote:
> Drazen Kacar <dave srce hr> writes:

> > If Gnome build system was doing it right on Solaris, then you would
> > be able to patch gnome-libs in order to replace DB code with gdbm
> > code, recompile and reinstall the library (or libraries, I don't
> > know if a single library uses DB, or there are several) and
> > everything else would work without further intervention.
> 
> Frankly, I never had this problem, and GNOME build system at least
> -appears- to do everything right on Solaris.

It appears. Which may be good enough for some people. It could have been
lot worse, though.

> But attempting to install GNOME with Berkeley db 2.0 is not a good
> idea.

Why not? Works for me, although I don't use Gnome much, so I can't
really judge.

Anyway, on to examples which show what's wrong. If you do `ldd somelib.so'
and it doesn't show anything, the library is not built correctly. It's
not a bug, it just may cause a certain degree of inconvenience later.

Since almost all Gnome libraries show this behaviour, I don't know
what depends on what, so let's assume that only libgnome.so.x depends
on DB. DB has to be built with 1.x compatibility, so it's reasonable
to assume that libgnome.so.x uses 1.x API. Let's suppose that 2.x
or 3.x brings some features you need (I don't know if this really is
the case, but it's good enough for an example). So you produce a patch for
libgnome.so.x, put in proper #ifdefs and write the source which uses
other APIs. DB dependancy is somewhat specific, but very good for
illustration. Gnome has a permission to use it, as long as it doesn't
expose DB API. So non-free application can link with it via libgnome.so.x
and use it via API provided by libgnome.so.x, but not DB API. Which
means the usage within Gnome libraries is very restricted and controlled.
For all other purposes, DB is a foreign body. Gnome does not control
the API, does not control version numbers, does not control compatibility,
does not control anything at all.

But any version can be used from libgnome.so.x. Now, since you've
made source changes, you'll recompile libgnome.so.x and you'll want
to use it. Let's suppose your DB 1 had soname libdb.so.1 (which is
a perfectly normal thing for Solaris) and it lived in /opt/db1/lib.
You'll want to put DB 2 in /opt/db2/lib, because some other apps
might still need DB 1, so you can't remove it from your system.

This means that you'll need to use -R/opt/db2/lib when linking
your new libgnome.so.x. You can try to do that, but you'll find
that libtool throws the flag out. So you link by hand, which works and
then you install your new libgnome.so.x wherever the old one was
living. At that point you'll find that none of your Gnome applications
work any more, because they all have libdb.so.1 dependancy.

They don't need it, because they don't use DB API directly, so
they shouldn't link with it. If libgnome.so.x is the only part
that uses DB, only libgnome.so.x should depend on libdb.so.x.
That way you can replace DB 1 with something else without trouble.
But *-config scripts give -ldb or whatever was found by configure
script at the time when the original libgnome.so.x was built.
Which is wrong.

The same happens if you want to replace vendor X libraries with
X.org source release (which you might want to do on Solaris 2.6
which has X11R6.0 or on SOlaris 2.5.1 which has X11R5). You can
compile X sources, install them somewhere and then recompile
GDK and GTK and link them with the new X libraries. At which
point your GTK apps probably won't work any more, because they
are linked with the original Solaris X libraries (runpath and
all), although most of them don't use X API at all. So you'll
have to recompile the apps as well, although you shouldn't
be forced to.

Or you want to use lazy loading. Suppose you are writing an editor
which can work with curses or with X, depending on command line
option. If the user didn't specify that option, you don't have
to call any graphics function at all. Then you can link with
"cc -o myeditor ... -z lazyload -lgtk -z nolazyload ...". Which
means that dynamic loader won't load GTK library until your program
uses the first function from it. This has obvious performance
improvement if you don't use graphics mode, but it also means
that you can install the same editor binary on the system which
doesn't have X libraries at all. That's much more important in
some cases.

If you do this and link with GTK library which is built by the
default procedure, your editor won't run in graphics mode. The
first call to gtk_init() will load libgtk.so (it's not really
called like that, but it doesn't matter) and transfer control
to the function. It has a call to gdk_init(), I think. But
libgtk.so is by default not built with -lgdk, so dynamic loader
won't be able to find gdk_init() anywhere and it will have
to kill your process. If you use "...-z lazyload -lgtk -lgdk -z nolazyload"
it doesn't help.

Or you want to use Imlib or gdk-pixbuf. libtool throws out -R,
so loaders are not built with proper runpath for libjpeg, for example.
That leads to dlopen() failure when the library tries to load
the module. So Imlib defaults to ImageMagick, which works, but
it's a bit slow. If ImageMagick is not installed, then the whole
thing fails. If you're using gdk-pixbuf, then it just fails, because
the library doesn't execute processes behind your back. configure
script can't do much with this as long as libtool insists that
it knows how to build libraries. I've never seen a C source which
used libtool to build some library that actually produced ABI compliant
library by default. It's entirely impossible with the current libtool
incarnation. Most of them appear to work, because they are written
in C and C is not a very demanding language. If it was C++, the libraries
wouldn't work.

Another funny thing with lazy loading is that I could probably
reduce the number of libraries needed by gnome-terminal from 25+
to about 15 (on start-up, at least). That would require minor
source modifications and proper linking. But it's entirely
impossible to link things properly with the current build system.
I could do it by hand, but it's an excercise in S/M, because
every component of the build system (autoconf/automake/libtool/*-config)
does something to make it harder.

> -- 
> How to eff the ineffable?

Dunno. It was in the introduction of the book whose title I forgot...

-- 
 .-.   .-.    I don't work for my employer.
(_  \ /  _)
     |        dave srce hr
     |        dave fly srk fer hr