Re: overriding libdir?

[Ralf Wildenhues]

Hi Olly,

* Olly Betts wrote on Thu, Apr 13, 2006 at 05:29:26PM CEST:
> On 2006-04-13, Ralf Wildenhues <address@hidden> wrote:
> > * Olly Betts wrote on Thu, Apr 13, 2006 at 12:53:53AM CEST:
> >> 
> >> You probably also want to remove the .la file this installs:

> >> I don't know of a way to avoid installing it in the first place...
> >
> > Well, there is a point to having them in the first place.
> 
> I realise that there is in general (both for libraries and modules), but
> when building modules for a particular application that is known not to
> ever use .la files there isn't, is there?

Hmm.  Rather for documentation purposes then, I guess.

> In fact, for this use case what you probably want to be able to say to
> libtool is "build me only a shared module (and fail if you can't) and
> create it in the current directory (skipping the usually .la wrapper
> with the .so in the .libs subdirectory)".

Yes, but this would make the build machinery much more complicated.
The way it is now is cleaner, and less work.  For example, `make clean'
would have to know the module extension(s).  If you would even want to
do away with the uninstalled .la file, the `make' target would have to
know it, too.  Very very ugly in practice.  So we don't do it, simply.
Also libtool can be sure nobody else puts shared objects below '.libs'.

> That would make it cleaner to
> test the module without installing it too.  Currently I have to use
> this, which probably assumes things it shouldn't about how libtool
> works internally:
> 
> TESTS_ENVIRONMENT = $(PHP) -c php.ini -d extension_dir=.libs
> 
> (I realise I probably shouldn't use .libs explicitly but should get it
> from objdir in libtool -config, but even then it seems I'm relying
> on implementation details...)

If you want to get at '.libs' portably:
  eval `$LIBTOOL --config | grep "^objdir="`

then use $objdir.  But I think you could be using
  $LIBTOOL --mode=execute -dlopen modules/module1.la \
    $(PHP) -c php.ini ...

instead.  Except for the small design bug with execute mode, that if
you have the installed module dir as RPATH, then it's system-dependent
whether libtool can actually override that with $shlibpath_var.  But
if you don't do that, this should be fine.
(for a more hacky solution without design bug see this thread:
http://lists.gnu.org/archive/html/libtool/2006-02/msg00084.html 
I don't really like to recommend that much though, I'd rather like to
fix it cleanly.  Time..)

Cheers,
Ralf