Hello Ralf,
we are discussing rpath and libtool with the FreeWRL plugin for Firefox.
Basically the plugin will use some symbols from Firefox (X) and will
fork to load the FreeWRL binary.
I'd have compiled it naturally with gcc -shared. But using libtool in
the project top configure.ac make it's use project wide... I dont know
to use/don't use libtool in subdirectories.
On Debian package mailing list and on DejaVu Libre mailing list similar
discussion occurred. "How to design & build a browser plugin ?".
Anyway with the proper definitions in Makefile.am I'm compiling the
plugin.
---
plugin_LTLIBRARIES = libFreeWRLplugin.la
plugindir=$(PLUGIN_DIR) # configure puts in it /usr/lib/mozilla/plugins
libFreeWRLplugin_la_LDFLAGS = -avoid-version $(AM_LDFLAGS)
#include sources...
---
This produces the following command line:
/bin/bash ../../libtool --tag=CC --mode=link gcc -g -O2 -avoid-version -o
libFreeWRLplugin.la -rpath /usr/lib/mozilla/plugins plugin_main.lo npunix.lo
internal_version.lo
libtool: link: gcc -shared .libs/plugin_main.o .libs/npunix.o
.libs/internal_version.o -Wl,-soname -Wl,libFreeWRLplugin.so -o
.libs/libFreeWRLplugin.so
Why -rpath /usr/lib/mozilla/plugins ???
The rpath troubles me. I think that rpath would be use to specify
library path needed by the shared object. Not the path where it is
supposed to be installed. Am I right ?
Cheers,
Michel
----- Message Transféré -----
Date: Tue, 10 Feb 2009 11:14:40 -0500
De: "Ian Stakenvicius, Aerobiology Research" <i...@aerobiology.ca>
À: Michel Briand <michelbri...@free.fr>
Cc: "John A. Stewart" <alex.stew...@crc.ca>
Sujet: Re: FreeWRL plugin, libtool problem
To elaborate further:
From my research, rpath is absolutely required to use libtool, and rpath
is supposed to be set to the final (installed) destination path of the
library file. So because of that, I believe that libtool is doing
exactly the right thing by using the value of @plugindir@ for -rpath.
Secondly, my goal for --with-plugindir is to provide the exact same
functionality that --bindir / --libdir / --datadir / etc.. flags provide
within configure and the build system as a whole. Those variables are
defined directly as 'libdir','bindir',etc. and are assigned via AC_SUBST
(see /usr/share/autoconf/acgeneral.m4 for more info). By default, these
values contain variables substitutable by MAKE to handle changes in
prefix or exec-prefix on the command line during installation. Further
to this, by specifying '[something]_LTLIBRARIES' in a Makefile.am,
autotools automatically uses @[something]dir@ as the installation
directory as well as -rpath. So, because of these things, the easiest
and most autotools-complete way of setting the plugin directory seems to
be:
plugindir="\$(libdir)/mozilla/plugins"
AC_SUBST([plugindir])
...and use plugin_LTLIBRARIES (and not plugindir all over again) in
/src/plugin/Makefile.am
Although it's not necessarily dependent on prefix, I believe the plugin
path _is_ dependent on LIBDIR. Some systems use /usr/lib, and I've seen
some use /usr/lib32 or /usr/lib64. And mozilla/firefox/etc. would be
installed in these as well. Since mozilla's plugins directory is going
to be built in LIBDIR too, I think it would be a more general approach
to provide a substitutable default path than to assign it directly to
what 32-bit Debian/Ubuntu uses.
I hope the above makes sense and covers all of the issues Michel
touched on.
Ian
Ian Stakenvicius, Aerobiology Research wrote:
> I specifically wanted to use "\$(libdir)/mozilla/plugins" so that the
> plugindir, like libdir/bindir/datadir/etc., would be modifyable
> according to a $prefix change during "make install". This is why I had
> to use AC_SUBST instead of AC_DEFINE_DIR, so that the literal $(libdir)
> would be transferred to the eventual Makefile instead of a substitution.
>
> Also, if in configure.ac we define "plugindir" directly, we do not have
> to define it again in Makefile.am (it'll be picked up properly
> automatically), which is how it's working now.
>
> Ian
>
> Michel Briand wrote:
>
>> "Ian Stakenvicius, Aerobiology Research" <i...@aerobiology.ca> - Fri, 06
>> Feb 2009 12:34:32 -0500
>>
>>
>>
>>> REALLY sorry about this -- the issue was that I used the wrong name in
>>> the AC_ARG_WITH code for --with-plugindir.
>>>
>>> I've fixed it in CVS. Note -- in order for $prefix to be substituted
>>> properly, I had to use AC_SUBST instead of AC_DEFINE_DIR.
>>>
>>> Ian
>>>
>>>
>>>
>> Hello Ian,
>>
>> your first solution was the good one :).
>>
>> In fact autotools are complex and specially libtool ;) and we often
>> mess up with them ;). But don't discourage, we'll more and more
>> knowledgeable about them in the times to come.
>>
>> The solution is to get user specified directory or detect it
>> automatically for the place where the plugin should be installed.
>>
>> Defining the PLUGIN_DIR variable with configure enable us to use that
>> variable in the Makefile.am.
>>
>> Just one mistake: don't forget that configure.ac use the Shell syntax,
>> not the Make syntax. I.e.:
>>
>> plugindir="${libdir}/mozilla/plugins" is good
>> plugindir="\$(libdir)/mozilla/plugins" is not good
>>
>> Anyway it's not dependent on ${libdir}. Browser is installed
>> in /usr/lib/mozilla. It does not depends on FreeWRL installation
>> prefix. So this value is "hard coded" to /usr/lib/mozilla/plugins.
>>
>> User (distro package maintainer) has the option to specify the directory
>> with the "--with-plugindir=" option.
>>
>> Furthermore libtool should be instructed not to use that directory for
>> rpath, though. I'm working on that topic now.
>>
>> Michel
>>
>>
>
>
>
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
