[Buildroot] Glibc LD_LIBRARAY_PATH error

[Mike Zick <minimod@morethan.org>]

On Tue, 1 Jul 2014 22:07:03 +0200
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> Dear Arnout Vandecappelle,
> 
> On Tue, 01 Jul 2014 20:11:45 +0200, Arnout Vandecappelle wrote:
> 
> > >> > my problem was solved by your solution I mean using "unset
> > >> > LD_LIBRARY_PATH"
> > > Ok. I'm not sure why we don't simply unset the LD_LIBRARY_PATH
> > > from our main Makefile. Probably we should just do it.
> > 
> >  I could imagine an ancient build host where the developer has to
> > build his own python2.7 or other buildroot-dependencies. Not really
> > realistic, though, because then the executable should just set its
> > DT_RPATH/DT_RUNPATH.
> 
> Yes.
> 
> >  Also, we already have a check for LD_LIBRARY_PATH in
> > dependencies.sh. It just doesn't check for empty path elements,
> > only for . path elements.
> 
> Well, the idea would be to get rid of this check entirely, and replace
> it by a simple unexport in the main Makefile.
> 

What about the (I would hope, unusual) case where a user needs those
LD_LIBRARY_PATH settings to run a POST_**_SCRIPT ?

- - - -

Even a further out use case -
The applications requiring a LD_LIBRARY_PATH setting, where the
application(s) are used in a POST_**_SCRIPT, but the source isn't
available to build-in the appropriate DT_RUNPATH/DT_RPATH?

For this second use case -
How about putting a "host-patchelf" target in the host tools list?

This would allow the use case #2 above user to build the tool to
fix their host application to not require a LD_LIBRARY_PATH setting.

Note: 
In my few weeks of use; 
I have not been able to break ARM binaries with patchelf-0.8
regardless of the current documentation that claims ARM isn't
fully supported.

Mike
> What do you think?
> 
> Best regards,
> 
> Thomas