finding libraries for programs with doing clean builds

[Matt Rogers]

On Tue, Jan 10, 2006 at 01:58:26PM -0200, Thiago Macieira wrote:
> David Faure wrote:
> >On Friday 06 January 2006 15:00, Thiago Macieira wrote:
> >> Matt Rogers wrote:
> >> >I've tried to think of a good solution for this for the last couple
> >> > of days and I haven't come up with much of anything. Does anybody
> >> > else have some ideas on how to solve this? Obviously setting
> >> > LD_LIBRARY_PATH before running scons works, but there will be a lot
> >> > of directories that will need to be added once we get around to
> >> > doing things like compiling docs, etc. and I'm wondering if we can
> >> > do something better.
> >>
> >> The only solution is to duplicate what libtool does, which is to
> >> determine how to run a program linked against uninstalled libraries.
> >>
> >> Options are:
> >> 1) setting the proper environment variable when possible
> >> (DYLIB_LIBRARY_PATH, LD_LIBRARY_PATH, etc.)
> >>
> >> 2) relinking the program if no other suitable method is found
> >>
> >> Note that a standard Linux uses option #2, because LD_LIBRARY_PATH
> >> won't work on a standard KDE installation that used --rpath.
> >
> >But this can be fixed with your "new-ldtags-whatever", right? i.e. We
> > can switch "standard Linux" to option 1) as long as we use the right
> > method of setting runpaths, in a way that still makes LD_LIBRARY_PATH
> > prevail?
> 
> Right. It was the original intention. We gave up on it because the new 
> ldtags had some side-effects generated by libtool. And I gave up on 
> fixing libtool.
> 
> When we have a nice Python script replacing libtool and throwing away all 
> the legacy support (including systems where LD_LIBRARY_PATH doesn't work, 
> like a standard KDE installation on Linux today), it'll be much easier.
> 

I'm quite confused about which cases would cause LD_LIBRARY_PATH to not
work, since kconfig_compiler ran for me after I had set LD_LIBRARY_PATH.
I guess this just means that my system isn't broken? ;)
--
Matt