[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: overriding libdir?
From: |
Ralf Wildenhues |
Subject: |
Re: overriding libdir? |
Date: |
Thu, 13 Apr 2006 18:03:56 +0200 |
User-agent: |
Mutt/1.5.11 |
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
Re: overriding libdir?, Alexandre Duret-Lutz, 2006/04/13