libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

custom wrapper script hooks


From: Havoc Pennington
Subject: custom wrapper script hooks
Date: 17 May 2001 17:50:00 -0400
User-agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7

Hi,

I've been setting up the 4 packages glib, pango, atk, and gtk+ to
build as part of one giant tarball.

So this means I link each library against the libtool libs in the
builddir of the other libraries.

The problem here is getting our test and demo programs to run without
actually installing the packages. The issue is that the libraries
depend on various files installed to known locations. 

For example, Pango installs a font configuration file in sysconfdir.

When running a test or demo program prior to installation, it can't
find the files in sysconfdir, obviously. Pango supports a
PANGO_RC_FILE env variable, so we hack around the issue with code like
this in each test program:

  if (file_exists ("./pangorc")
    putenv ("PANGO_RC_FILE=./pangorc");

Or in GTK, where we need to find image loading modules for dlopen()
and an input method config file, we have the following broken hack:
  
  if (g_file_test ("../../gdk-pixbuf/.libs/libpixbufloader-pnm.so",
                   G_FILE_TEST_EXISTS))
    {
      putenv ("GDK_PIXBUF_MODULEDIR=../../gdk-pixbuf/.libs");
      putenv ("GTK_IM_MODULE_FILE=../../modules/input/gtk.immodules");
    }

I'm setting this up to build without installing Pango, so the GTK
programs now all need the Pango hack added as well...

One of the problems with these hacks is that the demo programs
actually get installed. But then we have an installed program with
these bizarre hacks in it, and you can even imagine it being a
security issue.


Getting around to the point: this situation is pretty much equivalent
to setting LD_LIBRARY_PATH in the libtool wrapper scripts around the
test programs. So what would you think of a solution as follows:

 - a libtool option such as "-wrapper-script-hook mycode.sh"
 - the option forces a wrapper script to be created in all cases
 - it inserts mycode.sh into the wrapper script

So mycode.sh.in would contain something like:

 export address@hidden@
 export address@hidden@
 export address@hidden@

or whatever, mycode.sh is created by configure, and then the wrapper
script ends up with those exports in it, so test programs run nicely.

Does that sound like a reasonable feature?

Havoc









reply via email to

[Prev in Thread] Current Thread [Next in Thread]