[Buildroot] Relocatable internal toolchain

[Buildroot] Relocatable internal toolchain

[Wolfgang Grandegger]

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.

[Buildroot] Relocatable internal toolchain

[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);
- 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

[Buildroot] Relocatable internal toolchain

[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.

Wolfgang.

[Buildroot] Relocatable internal toolchain

[Jérôme Pouiller]

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

[Buildroot] Relocatable internal toolchain

[Wolfgang Grandegger]

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.

[Buildroot] Relocatable internal toolchain

[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).

>
> 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

[Buildroot] Relocatable internal toolchain

[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...

Thanks,

Wolfgang.

[Buildroot] Relocatable internal toolchain

[Wolfgang Grandegger]

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.

[Buildroot] Relocatable internal toolchain

[Wolfgang Grandegger]

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.