Re: Setting environment variable in libtool wrapper?

[Ralf Wildenhues]

Hi Geoffrey,

* Geoffrey Hutchison wrote on Mon, Feb 20, 2006 at 05:19:42PM CET:
> 
> >Would it also load modules without specifying a directory?  IOW: would
> >adjusting the uninstalled program's DT_RPATH (or equivalent) or
> >LD_LIBRARY_PATH (or equivalent) be sufficient, too?
> 
> Currently, no. But that's an easy change.

Good, noted for later.  Thanks!

> In the meantime, can you think of any way to handle a workaround?  
> Maybe something like install-hook in Automake that would allow me to  
> add an "export ${VAR}" after "make" is run? If I hack ltmain.sh, will  
> autoconf variables be substituted (i.e., hand-editing the binary  
> libtool wrapper in ltmain.sh)?

First, there is a documented way to add directories to the runtime
path:

  libtool --mode=execute -dlopen ../path/to/uninstalled/module.la \
    ./program

It fails iff
- `program' has a run path entry pointing to installed modules, and also
- shlibpath_overrides_runpath=yes on the system in question.


I have another kludge to emulate what you need, in the form I described
above, for many but possibly not all systems:

For each directory in the build tree in which your modules reside:
- create a dummy file (with one exported symbol),
- link it as a libtool module (use both `-module' and `-rpath'), for
  good measure also `-avoid-version',
- "dlpreopen" it from your programs:
   .../libtool --mode=link $CC -o program prog.o -dlpreopen ../mods/dummy.la

Then, libtool should create a shell wrapper for `program' and, that
should cause the uninstalled program to be executed with an additional
run path pointing to the module directory.

Several issues to be noted here:
- Actually, one would guess that `-dlopen' would be the right thing
  here, not `-dlpreopen', and that the latter would not need this.
  Still need to investigate, though.

- You should probably be able to just use one (or several) of your
  actual modules to pass instead of the dummy, at the expense of having
  a few more actual entries in the preloading symbol table.

- Using just something like `static int dummy=0;' (i.e., no exported
  symbols) will fail the preloading mechanism on AIX.

- I'm not so sure whether I want to sell the above as "solution".
  If it breaks, you get to keep the pieces.. but I'd really like to hear
  about it, so we can think about unbreaking in some way.

- The installed program will not have the run path pointing to the build
  tree.  This means relinking is definitely necessary (either at install
  time, or at the time the uninstalled program is first executed; this
  depends on fast-install mode).  This seems to work properly in this
  case.

- You are advised to not rely on the fact that finding the modules is
  achieved by either means of run paths or environment variables: plans
  are to change this in some situations in the future (to the benefit of
  less relinking).

> One possibility that occurred to me was to kludge BUILT_SOURCES to
> create a dummy header and export the environment variable there. But
> it might cover 80% of users/developers who just run "make all".

I would not do that, it sounds too much like replicating logic.

Hope this helps.

Cheers,
Ralf