libtool
[Top][All Lists]
Advanced

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

Re: Relocatable .la files?


From: Ralf Wildenhues
Subject: Re: Relocatable .la files?
Date: Mon, 18 Dec 2006 20:23:41 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

* Benoit Sigoure wrote on Mon, Dec 18, 2006 at 07:32:13PM CET:
> Quoting Ralf Wildenhues <address@hidden>:
> >* Benoit Sigoure wrote on Mon, Dec 18, 2006 at 02:35:43PM CET:
> >>
> >>what's the right why of distributing binary packages that are relocatable?
> >
> >With shared libraries: in general, that is not possible portably.
[...]
> Alright I knew that, in that case, let's assume I only use static libraries 
> on
> Linux if that helps. What is The Recommended Way of distributing relocatable
> binaries (actually relocatable libraries in this case) ?

I can offer this link:
http://lists.gnu.org/archive/html/bug-gnulib/2003-03/msg00020.html

and for .la files I could probably hack up a sed script that works for
you (but not for every conceivable case).  I don't have enough
experience with either to call it The Recommended Way.  ;-)

> >This, however, looks like a bug somewhere, iff libjpeg was built during
> >the build.
> 
> You made an important point "iff libjpeg was built". No, it wasn't.
> Actually I ran svn up, ran configure again to set the prefix and ran
> make. Several things were recompiled, but not libjpeg. That's a bit
> unexpected but I can guess why this might not be seen as a bug in
> itself.

Probably not.  Well, at least currently automake doesn't place an
explicit dependency of libraries on either their Makefile or
config.status (either one would help you).  So you'd have to force
rebuilding the library yourself.

In case 'make clean && make' is too expensive, this cleans only libtool
libraries, fairly portably, in a top build directory:
  find . -name \*.la | xargs ./libtool --mode=clean rm -f

Cheers,
Ralf




reply via email to

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