* [Buildroot] Relocatable internal toolchain @ 2017-01-26 8:25 Wolfgang Grandegger 2017-01-26 10:47 ` Samuel Martin 0 siblings, 1 reply; 9+ messages in thread From: Wolfgang Grandegger @ 2017-01-26 8:25 UTC (permalink / raw) To: buildroot Hello, I prefer a relocatable (internal) toolchain and before digging deeper... Are there any plans in that direction? I realized some attempts (patches) to make the buildroot toolchain relocatable but they have not (yet) been accepted. What are the pros and cons? Are there principle problems? Wolfgang. ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] Relocatable internal toolchain 2017-01-26 8:25 [Buildroot] Relocatable internal toolchain Wolfgang Grandegger @ 2017-01-26 10:47 ` Samuel Martin 2017-01-26 17:46 ` Wolfgang Grandegger ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Samuel Martin @ 2017-01-26 10:47 UTC (permalink / raw) To: buildroot Hi Wolfgang, all, On Thu, Jan 26, 2017 at 9:25 AM, Wolfgang Grandegger <wg@grandegger.com> wrote: > Hello, > > I prefer a relocatable (internal) toolchain and before digging deeper... Are > there any plans in that direction? I realized some attempts (patches) to > make the buildroot toolchain relocatable but they have not (yet) been > accepted. What are the pros and cons? Are there principle problems? Yes, there are plans for this. There had been a couple of the series posted on this topic (the latest one [1]). And we talked about this during the last Buildroot Meeting, you can check the report [2] for detailed conclusions. To sum-up: - Producing the relocatable host tools will be addressed step-by-step; - Preparatory changes making buildroot using absolute canonical paths are already merged [4]; - Next step: fixing RPATH in host tools binaries thanks to some patchelf [3] features to be implemented and upstreamed (this should be enough to meet Buildroot needs); - Cleaning up RPATH in target binaries is delayed. Unfortunately, I got no freetime to spend on patchelf source code [3] since the meeting. If you are interested in or want to take over this topic, don't hesitate to drop a message on the Buildroot mailing list. Regards, [1] http://lists.busybox.net/pipermail/buildroot/2016-April/159422.html [2] http://lists.busybox.net/pipermail/buildroot/2016-October/175088.html [3] https://github.com/NixOS/patchelf [4] http://lists.busybox.net/pipermail/buildroot/2016-October/174886.html > > Wolfgang. > _______________________________________________ > buildroot mailing list > buildroot at busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot -- Samuel ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] Relocatable internal toolchain 2017-01-26 10:47 ` Samuel Martin @ 2017-01-26 17:46 ` Wolfgang Grandegger 2017-01-30 7:31 ` Wolfgang Grandegger 2017-01-26 19:52 ` Jérôme Pouiller 2017-02-21 8:53 ` Wolfgang Grandegger 2 siblings, 1 reply; 9+ messages in thread From: Wolfgang Grandegger @ 2017-01-26 17:46 UTC (permalink / raw) To: buildroot Hi Samuel, Am 26.01.2017 um 11:47 schrieb Samuel Martin: > Hi Wolfgang, all, > > On Thu, Jan 26, 2017 at 9:25 AM, Wolfgang Grandegger <wg@grandegger.com> wrote: >> Hello, >> >> I prefer a relocatable (internal) toolchain and before digging deeper... Are >> there any plans in that direction? I realized some attempts (patches) to >> make the buildroot toolchain relocatable but they have not (yet) been >> accepted. What are the pros and cons? Are there principle problems? > > Yes, there are plans for this. Great! > There had been a couple of the series posted on this topic (the latest one [1]). > And we talked about this during the last Buildroot Meeting, you can > check the report [2] for detailed conclusions. > To sum-up: > - Producing the relocatable host tools will be addressed step-by-step; > - Preparatory changes making buildroot using absolute canonical paths > are already merged [4]; > - Next step: fixing RPATH in host tools binaries thanks to some > patchelf [3] features to be implemented and upstreamed (this should be > enough to meet Buildroot needs); > - Cleaning up RPATH in target binaries is delayed. > > Unfortunately, I got no freetime to spend on patchelf source code > [3] since the meeting. Thanks for the quick introduction... > If you are interested in or want to take over this topic, don't > hesitate to drop a message on the Buildroot mailing list. I will have a closer look. Let's see if I can do something. Wolfgang. ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] Relocatable internal toolchain 2017-01-26 17:46 ` Wolfgang Grandegger @ 2017-01-30 7:31 ` Wolfgang Grandegger 2017-01-30 8:14 ` Samuel Martin 0 siblings, 1 reply; 9+ messages in thread From: Wolfgang Grandegger @ 2017-01-30 7:31 UTC (permalink / raw) To: buildroot Hi Samuel, Am 26.01.2017 um 18:46 schrieb Wolfgang Grandegger: > Hi Samuel, > > Am 26.01.2017 um 11:47 schrieb Samuel Martin: >> Hi Wolfgang, all, >> >> On Thu, Jan 26, 2017 at 9:25 AM, Wolfgang Grandegger >> <wg@grandegger.com> wrote: >>> Hello, >>> >>> I prefer a relocatable (internal) toolchain and before digging >>> deeper... Are >>> there any plans in that direction? I realized some attempts (patches) to >>> make the buildroot toolchain relocatable but they have not (yet) been >>> accepted. What are the pros and cons? Are there principle problems? >> >> Yes, there are plans for this. > > Great! > >> There had been a couple of the series posted on this topic (the latest >> one [1]). >> And we talked about this during the last Buildroot Meeting, you can >> check the report [2] for detailed conclusions. >> To sum-up: >> - Producing the relocatable host tools will be addressed step-by-step; >> - Preparatory changes making buildroot using absolute canonical paths >> are already merged [4]; >> - Next step: fixing RPATH in host tools binaries thanks to some >> patchelf [3] features to be implemented and upstreamed (this should be >> enough to meet Buildroot needs); >> - Cleaning up RPATH in target binaries is delayed. >> >> Unfortunately, I got no freetime to spend on patchelf source code >> [3] since the meeting. > > Thanks for the quick introduction... > >> If you are interested in or want to take over this topic, don't >> hesitate to drop a message on the Buildroot mailing list. > > I will have a closer look. Let's see if I can do something. Buildroot's build system is quite new too me. At a first glance it's rather heavy stuff! So I first tried the patches you mentioned to see what I get. After some tweaking due to "file permissions" and "file in use" issues with patchelf, the build did succeed. But subsequent builds then required setting LD_LIBRARY_PATH for the host tools. Then I moved the buildroot output directory to a different location to see if relocation, as I understand it, works. My test cases are some out-of-tree QT5 examples: $ cd <a-path>/examples $ <path-to-buildroot-output>/host/usr/bin/qmake Could not find qmake configuration file devices/linux-buildroot-g++. Error processing project file: /home/wolf/junk/examples/examples.pro How do I set the new path to the toolchain. Likely I have missed something. Apart from the "rpath", the path to the build directory is also in many text (configuration scripts, etc.) files. What did work for me was replacing the path to the build directory ("<buildroot-output>/host/usr") with the new location in all text files. Not sure if we speak/think about the same "relocation" behaviour. Wolfgang. ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] Relocatable internal toolchain 2017-01-30 7:31 ` Wolfgang Grandegger @ 2017-01-30 8:14 ` Samuel Martin 2017-01-30 9:36 ` Wolfgang Grandegger 0 siblings, 1 reply; 9+ messages in thread From: Samuel Martin @ 2017-01-30 8:14 UTC (permalink / raw) To: buildroot Hi Wolfgang, all, On Mon, Jan 30, 2017 at 8:31 AM, Wolfgang Grandegger <wg@grandegger.com> wrote: > > Buildroot's build system is quite new too me. At a first glance it's rather > heavy stuff! So I first tried the patches you mentioned to see what I get. > After some tweaking due to "file permissions" and "file in use" issues with > patchelf, the build did succeed. But subsequent builds then required setting > LD_LIBRARY_PATH for the host tools. Then I moved the buildroot output > directory to a different location to see if relocation, as I understand it, > works. My test cases are some out-of-tree QT5 examples: > > $ cd <a-path>/examples > $ <path-to-buildroot-output>/host/usr/bin/qmake > Could not find qmake configuration file devices/linux-buildroot-g++. > Error processing project file: /home/wolf/junk/examples/examples.pro > > How do I set the new path to the toolchain. Likely I have missed something. I have no clue about this, but a quick google search gives me a possible way to fix/workaround this [5] (with no warranty at all). > > Apart from the "rpath", the path to the build directory is also in many text > (configuration scripts, etc.) files. What did work for me was replacing the > path to the build directory ("<buildroot-output>/host/usr") with the new > location in all text files. > > Not sure if we speak/think about the same "relocation" behaviour. Yes we are, I just forgot to give the main link to this task, which details many things to fix/support for a complete relocatable SDK. Note that the series I posted just dealt with the rpath point so far, unstacking one point after the other. > > Wolfgang. Regards, [5] http://doc.qt.io/qt-5/qmake-environment-reference.html [6] http://elinux.org/Buildroot#Core_Buildroot_infrastructure -- Samuel ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] Relocatable internal toolchain 2017-01-30 8:14 ` Samuel Martin @ 2017-01-30 9:36 ` Wolfgang Grandegger 2017-02-01 8:13 ` Wolfgang Grandegger 0 siblings, 1 reply; 9+ messages in thread From: Wolfgang Grandegger @ 2017-01-30 9:36 UTC (permalink / raw) To: buildroot Hi Samuel, Am 30.01.2017 um 09:14 schrieb Samuel Martin: > Hi Wolfgang, all, > > On Mon, Jan 30, 2017 at 8:31 AM, Wolfgang Grandegger <wg@grandegger.com> wrote: >> >> Buildroot's build system is quite new too me. At a first glance it's rather >> heavy stuff! So I first tried the patches you mentioned to see what I get. >> After some tweaking due to "file permissions" and "file in use" issues with >> patchelf, the build did succeed. But subsequent builds then required setting >> LD_LIBRARY_PATH for the host tools. Then I moved the buildroot output >> directory to a different location to see if relocation, as I understand it, >> works. My test cases are some out-of-tree QT5 examples: >> >> $ cd <a-path>/examples >> $ <path-to-buildroot-output>/host/usr/bin/qmake >> Could not find qmake configuration file devices/linux-buildroot-g++. >> Error processing project file: /home/wolf/junk/examples/examples.pro >> >> How do I set the new path to the toolchain. Likely I have missed something. > > I have no clue about this, but a quick google search gives me a > possible way to fix/workaround this [5] (with no warranty at all). See below... >> Apart from the "rpath", the path to the build directory is also in many text >> (configuration scripts, etc.) files. What did work for me was replacing the >> path to the build directory ("<buildroot-output>/host/usr") with the new >> location in all text files. >> >> Not sure if we speak/think about the same "relocation" behaviour. > > Yes we are, I just forgot to give the main link to this task, which > details many things to fix/support for a complete relocatable SDK. > Note that the series I posted just dealt with the rpath point so far, > unstacking one point after the other. OK, I see! The script I mentioned does: for FILE in $(grep -r "${FINDSTR}" . -l ) ; do if [ ! -h ${FILE} ] && [ -n "$(file ${FILE} | cut -d: -f2 | grep text )" ] then echo ${FILE} sed -i s,"${FINDSTR}",${REPLACESTR},g ${FILE} fi done Such a script is mentioned in [6]. Relocation works fine (for me) also without fixing "rpath", and for the qmake examples above. > [5] http://doc.qt.io/qt-5/qmake-environment-reference.html > [6] http://elinux.org/Buildroot#Core_Buildroot_infrastructure It's getting clearer what has do be done... Thanks, Wolfgang. ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] Relocatable internal toolchain 2017-01-30 9:36 ` Wolfgang Grandegger @ 2017-02-01 8:13 ` Wolfgang Grandegger 0 siblings, 0 replies; 9+ messages in thread From: Wolfgang Grandegger @ 2017-02-01 8:13 UTC (permalink / raw) To: buildroot Hello, Am 30.01.2017 um 10:36 schrieb Wolfgang Grandegger: > Hi Samuel, > > Am 30.01.2017 um 09:14 schrieb Samuel Martin: >> Hi Wolfgang, all, >> >> On Mon, Jan 30, 2017 at 8:31 AM, Wolfgang Grandegger <wg@grandegger.com> wrote: >>> >>> Buildroot's build system is quite new too me. At a first glance it's rather >>> heavy stuff! So I first tried the patches you mentioned to see what I get. >>> After some tweaking due to "file permissions" and "file in use" issues with >>> patchelf, the build did succeed. But subsequent builds then required setting >>> LD_LIBRARY_PATH for the host tools. Then I moved the buildroot output >>> directory to a different location to see if relocation, as I understand it, >>> works. My test cases are some out-of-tree QT5 examples: >>> >>> $ cd <a-path>/examples >>> $ <path-to-buildroot-output>/host/usr/bin/qmake >>> Could not find qmake configuration file devices/linux-buildroot-g++. >>> Error processing project file: /home/wolf/junk/examples/examples.pro >>> >>> How do I set the new path to the toolchain. Likely I have missed something. >> >> I have no clue about this, but a quick google search gives me a >> possible way to fix/workaround this [5] (with no warranty at all). > > See below... > >>> Apart from the "rpath", the path to the build directory is also in many text >>> (configuration scripts, etc.) files. What did work for me was replacing the >>> path to the build directory ("<buildroot-output>/host/usr") with the new >>> location in all text files. >>> >>> Not sure if we speak/think about the same "relocation" behaviour. >> >> Yes we are, I just forgot to give the main link to this task, which >> details many things to fix/support for a complete relocatable SDK. >> Note that the series I posted just dealt with the rpath point so far, >> unstacking one point after the other. > > OK, I see! The script I mentioned does: > > for FILE in $(grep -r "${FINDSTR}" . -l ) ; do > if [ ! -h ${FILE} ] && [ -n "$(file ${FILE} | cut -d: -f2 | grep text )" ] > then > echo ${FILE} > sed -i s,"${FINDSTR}",${REPLACESTR},g ${FILE} > fi > done > > Such a script is mentioned in [6]. Relocation works fine (for me) also > without fixing "rpath", and for the qmake examples above. > >> [5] http://doc.qt.io/qt-5/qmake-environment-reference.html >> [6] http://elinux.org/Buildroot#Core_Buildroot_infrastructure > > It's getting clearer what has do be done... Digging deeper... Is there a simple way of re-triggering the population of the host, staging and target trees without doing a make clean? Wolfgang. ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] Relocatable internal toolchain 2017-01-26 10:47 ` Samuel Martin 2017-01-26 17:46 ` Wolfgang Grandegger @ 2017-01-26 19:52 ` Jérôme Pouiller 2017-02-21 8:53 ` Wolfgang Grandegger 2 siblings, 0 replies; 9+ messages in thread From: Jérôme Pouiller @ 2017-01-26 19:52 UTC (permalink / raw) To: buildroot Hello Samuel, On Thursday 26 January 2017 11:47:58 Samuel Martin wrote: > On Thu, Jan 26, 2017 at 9:25 AM, Wolfgang Grandegger <wg@grandegger.com> wrote: [...] > - Cleaning up RPATH in target binaries is delayed. For information, in my "Reproducible build" series, I wrote patches that remove erroneous RPATH entries from target binaries. It is implemented by patches 11 to 19: http://lists.busybox.net/pipermail/buildroot/2016-December/thread.html#180130 -- J?r?me Pouiller, Sysmic Embedded Linux specialist http://www.sysmic.fr ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] Relocatable internal toolchain 2017-01-26 10:47 ` Samuel Martin 2017-01-26 17:46 ` Wolfgang Grandegger 2017-01-26 19:52 ` Jérôme Pouiller @ 2017-02-21 8:53 ` Wolfgang Grandegger 2 siblings, 0 replies; 9+ messages in thread From: Wolfgang Grandegger @ 2017-02-21 8:53 UTC (permalink / raw) To: buildroot Hello Samuel, all more on that topic... Am 26.01.2017 um 11:47 schrieb Samuel Martin: > Hi Wolfgang, all, > > On Thu, Jan 26, 2017 at 9:25 AM, Wolfgang Grandegger <wg@grandegger.com> wrote: >> Hello, >> >> I prefer a relocatable (internal) toolchain and before digging deeper... Are >> there any plans in that direction? I realized some attempts (patches) to >> make the buildroot toolchain relocatable but they have not (yet) been >> accepted. What are the pros and cons? Are there principle problems? > > Yes, there are plans for this. > > There had been a couple of the series posted on this topic (the latest one [1]). > And we talked about this during the last Buildroot Meeting, you can > check the report [2] for detailed conclusions. > To sum-up: > - Producing the relocatable host tools will be addressed step-by-step; > - Preparatory changes making buildroot using absolute canonical paths > are already merged [4]; > - Next step: fixing RPATH in host tools binaries thanks to some > patchelf [3] features to be implemented and upstreamed (this should be > enough to meet Buildroot needs); I have now implemented "patchelf --make-rpath-relative ROOTDIR ..:" following closely your related patches. Before starting the up-streaming process, I first want to get some feedback here. Does it fit our needs? Any other ideas or comments? It would be nice to get rid of the "readelf" scripts as well. We could call "patchelf" on any regular file and simply ignore the errors (not an ELF file, not dynamic or not shared). That's fast but maybe a bit too hackish. Having an extra option for that purpose might be better/cleaner. Below is the preliminary patchelf patch. Wolfgang. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-02-21 8:53 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-01-26 8:25 [Buildroot] Relocatable internal toolchain Wolfgang Grandegger 2017-01-26 10:47 ` Samuel Martin 2017-01-26 17:46 ` Wolfgang Grandegger 2017-01-30 7:31 ` Wolfgang Grandegger 2017-01-30 8:14 ` Samuel Martin 2017-01-30 9:36 ` Wolfgang Grandegger 2017-02-01 8:13 ` Wolfgang Grandegger 2017-01-26 19:52 ` Jérôme Pouiller 2017-02-21 8:53 ` Wolfgang Grandegger
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.