From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnout Vandecappelle Date: Wed, 02 Jul 2014 08:47:33 +0200 Subject: [Buildroot] Glibc LD_LIBRARAY_PATH error In-Reply-To: <20140701160904.34c80062@core2quad.morethan.org> References: <20140628000126.4bfd6329@free-electrons.com> <20140628083612.167f7b88@free-electrons.com> <20140628162843.41a203d7@free-electrons.com> <20140628174420.2fd3ed86@free-electrons.com> <53B2F9E1.7080609@mind.be> <20140701220703.0fa13b8a@free-electrons.com> <20140701160904.34c80062@core2quad.morethan.org> Message-ID: <53B3AB05.7050503@mind.be> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net On 01/07/14 23:09, Mike Zick wrote: > On Tue, 1 Jul 2014 22:07:03 +0200 > Thomas Petazzoni 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