Re: shared library dependencies (again)

[Owen Taylor <otaylor redhat com>]

James Henstridge <james daa com au> writes:

> Since libtool version 1.4 has just been released, I thought I would bring
> up the issue of adding support for shared library dependencies (since Owen
> said he didn't want to look at the problem until a stable libtool that
> handled them was released).
> 
> I filed a bug in bugzilla about this a while back, and have attached
> patches for glib, pango and gtk+ to it since then:
>   http://bugzilla.gnome.org/show_bug.cgi?id=50707
> 
> I haven't had any problems with the patches on my machine, and it fixes
> the dynamic loading problems with pygtk mentioned in the bug report.  I
> haven't seen any breakage caused by the build changes, which is promising.
> 
> The one issue with my build patches is compiling pango modules into
> libpango.  In order to have correct dependencies in the modules, libpango
> must be built first.  But to compile modules into libpango, the modules
> must be built first.  I haven't worked out how to address this.  The patch
> makes things work in the case where no modules are compiled into libpango.

I'd like to see these changes go in soon. But I think we have to
resolve this issueof included modules be resolved first. I admit to
being also puzzled as to how to do this.

The basic issue is that included modules must be built before 
pango as convenience libraries and then linked into libpangox,
etc. While modules built as dlloaded modules must, with James's
change, be built _after_ libpangox so they can depend on
libpangox.

Yet, the set of included modules is specified at configure time,
and this is useful a feature I don't want to lose. 

My only idea right now, is to make configure.in generate a shadow
symlinked copy of modules/ as included-modules/, have both
of these appear in the toplevel SUBDIRS, and use some hackery
to get different AM_CONDITIONAL defines defined in the two
trees. 

(This sounds like utter hell to get working reliably with 
sourcedir != builddir, etc, but not completely impossible.)

> These changes will benefit any programs that dlopen libgtk (or indirectly
> through a module linked to libgtk) without the RTLD_GLOBAL flag.  This is
> mainly language bindings, but there may be some other cases as well.

Well, the other big improvement we can get out of libtool-1.4 and
dependencies on uninstalled libraries is that GTK+ may actually
work on AIX (and BeOS, I guess) without manual makefile modification.

                                        Owen