[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/
pgpBKqFWHjcyb.pgp
Description: OpenPGP digital signature
- Developing against $HOME/lib libraries and LD_LIBRARY_PATH,
Paul \"LeoNerd\" Evans <=