libtool
[Top][All Lists]
Advanced

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

Problems creating convenience libraries on IRIX 6.5 if -rpath linker opt


From: Tuomas Jormola
Subject: Problems creating convenience libraries on IRIX 6.5 if -rpath linker option used
Date: Fri, 13 Jun 2008 14:23:24 +0300
User-agent: Mutt/1.5.13 (2006-08-11)

Hi,

I'm trying to compile glib 2.16.3 on IRIX 6.5 using SGI's MipsPro 7.4.3m
compiler toolchain. I'm using the custom prefix /opt/local for the stuff
I'm compiling. I want to setup run-time linker search path for the
binaries to the prefix so I'm using the following flags are used when
configuring:

CC="cc -64 -mips4 -c99" \
        CPPFLAGS=-I/opt/local/include \
        LDFLAGS="-rpath /opt/local/lib -L/opt/local/lib"
        ./configure --prefix=/opt/local ...

Glib has auxiliary library called libcharset, which is defined not to be
installed, snippet from glib/libcharset/Makefile.am:

noinst_LTLIBRARIES = libcharset.la

However, when I compiled libcharset, libtool does not produce static
libcharset.a as it's supposed to do but a shared library
libcharset.so.1.0 is linked instead.

I configured the same glib version on a Linux system with similar
configure options, but adapted for gcc/binutils. I looked at the
generated .la files on both systems and the libtool script the glib
configure script produced (it's using libtool version 1.5.24). I noticed
that on the SGI system, the line

libdir='/opt/local/lib'

is added to libcharset.la. On a Linux system the corresponding line is

libdir=''

Investigating the libtool script reveals that a library is considered
a convenience library only if the value of the libdir variable is empty.
On the SGI system this is not the case, and the library gets linked as
a shared library, and all the libraries that depend on the library (e.g.
libglib-2.0.la), are linked against the shared library. However, when
installing the package to the configured prefix, this auxiliary library
is not installed, resulting broken libglib-2.0.so.1 installation as the
needed libcharset.so.1.0 is nowhere to be found.

So how does this erroneous libdir variable is placed in the .la file of
a convenience library on the SGI system? It's because of this piece of
code in libtool:

        set dummy $rpath
        if test "$#" -gt 2; then
          $echo "$modename: warning: ignoring multiple \`-rpath's for a libtool 
library" 1>&2
        fi
        install_libdir="$2"

Value of the rpath variable is the argument to -rpath argument in
LDFLAGS, and it's value is assigned to variable install_libdir, which is
eventually written to the .la file. If I omit the -rpath argument in
LDFLAGS, the convenience library is linked statically, and
libglib-2.0.so.1 is linked bautifully against it.

So my question is what is this piece of code supposed to do in the first
place? Why setting the install directory for a library is based on the
possible rpath linker option, potentially hosing the whole
convenience library mechanism in place? How should this be fixed so that
one can use -rpath in LDFLAGS while linking would work like it should
be?

Regards,

-- 
Tuomas Jormola <address@hidden>

Attachment: signature.asc
Description: Digital signature


reply via email to

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