bug-libtool
[Top][All Lists]
Advanced

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

Re: Bug#117829: libtool problem building gwrapguile


From: Eric Gillespie, Jr.
Subject: Re: Bug#117829: libtool problem building gwrapguile
Date: Wed, 31 Oct 2001 16:49:09 -0500
User-agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (asparagus)

I spent an hour or so today trying to help John fix this, since
we originally suspected a g-wrap (what John calls gwrapguile) or
Debian packaging bug.  I have some more information.

John Goerzen <address@hidden> writes:

    > Of note is that if a previous version of gwrapguile is
    > installed on the build system, this behavior does not
    > appear.

Actually, this is not of note, but what causes it is.  In
g-wrapped/Makefile.am we find the following:

# are we supposed to use -rpath here?  info pages suggest not.

libgw_runtime_la_LDFLAGS = -rpath $(libdir) -module -export-dynamic
#libgw_runtime_la_LIBADD = \
#  @GUILE_LIBS@ \
#  -L$(LOCALPWD)/../libruntime-guile/.libs -lg-wrap-runtime-guile

libgw_runtime_la_LIBADD = \
  @GUILE_LIBS@ \
  ../libruntime-guile/libg-wrap-runtime-guile.la

The libgw_runtime_la_LDFLAGS use of rpath is of course wrong, not
due to the unfortunate decision of Debian to ban the use of rpath
(please let's not get into this flame war) but because the
resulting binary would have an rpath referring to paths in the
source directory.

The commented out lines look like the g-wrap developers
recognizing and trying to fix the problem, but really what
libgw_runtime_la_LIBADD does looks like it should work.  Isn't
that the whole point of .la files, after all?

So, what John did was simply remove the rpath bit, but of course
that doesn't work either.

-- 
Eric Gillespie, Jr. <*> address@hidden

"This movie sure is gory!"
"Yeah, but that's one cute pig."




reply via email to

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