[Buildroot] Glibc LD_LIBRARAY_PATH error

[Arnout Vandecappelle]

On 01/07/14 23:09, Mike Zick wrote:
> On Tue, 1 Jul 2014 22:07:03 +0200
> Thomas Petazzoni <thomas.petazzoni at 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?

 To be honest, I think that use case is so far out that we don't need to
consider it, and anyway the user has two easy solutions:

- don't use a POST_**_SCRIPT but wrap something around the Makefile;

- create a wrapper for the binaries that require LD_LIBRARY_PATH (like java apps
typically do).

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

 You wouldn't want to patch an out-of-buildroot-tree tool on every build
invocation, would you? Especially since that tool is probably in some shared,
non-writable place...


 Regards,
 Arnout

> 
> 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
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F