[Top][All Lists]

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

Re: Fw: FreeWRL plugin, libtool problem

From: Ralf Wildenhues
Subject: Re: Fw: FreeWRL plugin, libtool problem
Date: Thu, 12 Feb 2009 19:28:17 +0100
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

Hello Michel,

* Michel Briand wrote on Thu, Feb 12, 2009 at 03:41:42PM CET:
> plugin_LTLIBRARIES =
> plugindir=$(PLUGIN_DIR) # configure puts in it /usr/lib/mozilla/plugins
> libFreeWRLplugin_la_LDFLAGS = -avoid-version $(AM_LDFLAGS)

> This produces the following command line:
> /bin/bash ../../libtool --tag=CC   --mode=link gcc  -g -O2 -avoid-version    
> -o -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, -o 
> .libs/
> Why -rpath /usr/lib/mozilla/plugins ???

Quoting '( mode':

| `-rpath LIBDIR'
|      If OUTPUT-FILE is a library, it will eventually be installed in
|      LIBDIR.  If OUTPUT-FILE is a program, add LIBDIR to the run-time
|      path of the program.

It seems weird, and it is, but somebody chose '-rpath' to have this
rather unusual meaning for libtool.

> 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 ?

Not in this case; you are thinking about the ld option -rpath, typically
passed to compilers as -Wl,-rpath,...  But that's not what the above
means to libtool, at least not in the case of creating a library.  It
does not cause /usr/lib/mozilla/plugins to be added to the run path of
the library.

Hope that helps.  I haven't read the rest, so if there were more
questions hidden there, please ping.


reply via email to

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