Quoth Owen Taylor on Sun, Oct 20, 2002 at 04:25:16PM -0400: > David Bustos <david bustos name> writes: > > Why do glib and gtk+ include such an odd version of ltmain.sh? It > > ... > > The libtool distributed with GLib and GTK+ includes a patch > necessary for correct installation in a different directory > than the configured directory. > > However, the patch does require a "strict" setup ... if you > configure with --prefix=/usr --sysconfdir=/etc, then > installing into: > > libdir = /foo/usr/lib > sysconfdir = /foo/etc > > Will work. > > libdir = /foo/lib > sysconfdir = /foo/etc > > Won't. This is probably the limitation you are complaining > about. Ah. So your patch causes libtool to support only moving the tree in its entirity. That explains why it's failing in my case; my site supports multiple processors, so we must split the tree into processor-specific and -independent parts. processor-specific files go into /repository/$PROC/$PKG and platform-independent files go into /repository/share/$PKG, where PROC is the processor and PKG is the package name (glib-2.0.6 in this case). Symlinks are then installed to reconstitute the tree in /repository. Since this is apparently uncommon, I don't expect you to support this, but... > If you use stock libtool you will either get failure on installation, > or worse, a mislinked install. to work around this I've been running libtoolize --force before configuring and installing, which succeed. How do I know if the install is being mislinked? David
Attachment:
pgp6Lnol4dgMc.pgp
Description: PGP signature