libtool
[Top][All Lists]
Advanced

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

Developing against $HOME/lib libraries and LD_LIBRARY_PATH


From: Paul \"LeoNerd\" Evans
Subject: Developing against $HOME/lib libraries and LD_LIBRARY_PATH
Date: Thu, 16 Nov 2017 17:01:37 +0000

Hi all,

I've come up against an awkward situation using libtool, and I wonder
if I could ask for some advice on what I'm probably doing wrong here.

I'm developing two different C libraries; lets just call them A and B.
A is fairly standalone, and B depends on A.

Using libtool, I can develop on A fine. In particular, it has some
internal unit-tests which I run using `libtool --mode=exec`. These run
OK.

Using libtool, I can develop on B just fine, provided the A library is
installed as a real system package. The linker can find it by the
normal mechanisms and it lives in /usr/lib along with other system
things. All is good. Library B also has some unit-tests that are
executed with `libtool --mode=exec`. So far so good.

But now suppose I have a possible change I want to make that needs
edits in both libraries. I don't want to build a new system package yet
and upset all the other users on this box. That's fine, I can just
install library A into my $HOME directory using

  $ make install PREFIX=$HOME

In order to be able to test programs that use library A, I'm going to
need to set LD_LIBRARY_PATH now so they can find the library here in
preference to the system-installed one, so in my .profile I use

  export LD_LIBRARY_PATH=$HOME/lib

But now, that upsets every use of `libtool --exec` to run any of the
unit tests for my libraries in their source code (for both libraries A
and B). With LD_LIBRARY_PATH set in the environment, the libtool
wrapper script no longer sets it up at all, meaning that `libtool
--exec` on a unit test just sees the system-packaged versions of each
library. This means I can't test the new code I just write in library
A, because the unit-test executables don't see it.

I could make unit tests for library A itself run fine by entirely
defeating the LD_LIBRARY_PATH mechanism again, if I

  $ LD_LIBRARY_PATH= make test

But what of library B? It has to be able to see its own locally-build
library in $CWD/.libs *and* library A in $HOME/lib. So I could

  $ LD_LIBRARY_PATH=`pwd`/.libs:$LD_LIBRARY_PATH make test

But at that point I really feel like I am fighting against libtool,
rather than it helping me do this right.

So, what am I doing wrong here?

Alternatively, am I using this entire setup in its intended way, but
libtool just isn't playing ball with me?


(this question also posted at
  
http://leonerds-code.blogspot.co.uk/2017/11/developing-against-homelib-libraries.html
)

-- 
Paul "LeoNerd" Evans

address@hidden      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/

Attachment: pgpBKqFWHjcyb.pgp
Description: OpenPGP digital signature


reply via email to

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