SDK feedback

SDK feedback

[Jan Kiszka]

Hi Maksim,

finally, I actually used the SDK on an ARM target, and it worked nicely! One 
question and one feature request, though:

I did not do the chroot dance and rather looked for a way to use the cross 
compiler directly. And it /seems/ to work, at least for the trivial case:

export LD_LIBRARY_PATH=/path-to-sdk/usr/lib/x86_64-linux-gnu/
sdk/usr/bin/arm-linux-gnueabihf-gcc --sysroot /path-to-sdk \
     -o hello hello.c

Does this make sense, at least for the classic "I need a crosscompiler and the 
corresponding target libs" case? When will it start to break?


And then I noticed that the deployed SDK image could be a bit slimmer, 
specifically by purging /var/cache/apt prior to packaging. Too lazy now to write 
my own patch. :)

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: SDK feedback

[Jan Kiszka]

On 11.09.18 19:55, Jan Kiszka wrote:
> Hi Maksim,
> 
> finally, I actually used the SDK on an ARM target, and it worked nicely! One 
> question and one feature request, though:
> 
> I did not do the chroot dance and rather looked for a way to use the cross 
> compiler directly. And it /seems/ to work, at least for the trivial case:
> 
> export LD_LIBRARY_PATH=/path-to-sdk/usr/lib/x86_64-linux-gnu/
> sdk/usr/bin/arm-linux-gnueabihf-gcc --sysroot /path-to-sdk \
>      -o hello hello.c
> 
> Does this make sense, at least for the classic "I need a crosscompiler and the 
> corresponding target libs" case? When will it start to break?

Forgot to state: my host was a SUSE 42.2.

> 
> 
> And then I noticed that the deployed SDK image could be a bit slimmer, 
> specifically by purging /var/cache/apt prior to packaging. Too lazy now to write 
> my own patch. :)
> 
> Thanks,
> Jan
> 

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: SDK feedback

[Maxim Yu. Osipov]

Hi Jan,

On 09/11/2018 08:57 PM, Jan Kiszka wrote:
> On 11.09.18 19:55, Jan Kiszka wrote:
>> Hi Maksim,
>>
>> finally, I actually used the SDK on an ARM target, and it worked 
>> nicely! One question and one feature request, though:
>>
>> I did not do the chroot dance and rather looked for a way to use the 
>> cross compiler directly. And it /seems/ to work, at least for the 
>> trivial case:
>>
>> export LD_LIBRARY_PATH=/path-to-sdk/usr/lib/x86_64-linux-gnu/
>> sdk/usr/bin/arm-linux-gnueabihf-gcc --sysroot /path-to-sdk \
>>      -o hello hello.c
>>
>> Does this make sense, at least for the classic "I need a crosscompiler 
>> and the corresponding target libs" case? When will it start to break?

Honestly I always played with chroot and never tried LD_LIBRARY_PATH 
approach in more complicated case, so I can't say which problems may pop up.

> Forgot to state: my host was a SUSE 42.2.

Nice to hear that it works under SUSE too
(I only tried sdk on Fedora box).

> 
>>
>>
>> And then I noticed that the deployed SDK image could be a bit slimmer, 
>> specifically by purging /var/cache/apt prior to packaging. Too lazy 
>> now to write my own patch. :)

Got it ;) (I will prepare the patch).

Thanks,
Maxim.

>>
>> Thanks,
>> Jan
>>
> 
> Jan
> 


-- 
Maxim Osipov
ilbers GmbH
Maria-Merian-Str. 8
85521 Ottobrunn
Germany
+49 (151) 6517 6917
mosipov@ilbers.de
http://ilbers.de/
Commercial register Munich, HRB 214197
General Manager: Baurzhan Ismagulov

Re: SDK feedback

[Jan Kiszka]

On 12.09.18 09:42, Maxim Yu. Osipov wrote:
> Hi Jan,
> 
> On 09/11/2018 08:57 PM, Jan Kiszka wrote:
>> On 11.09.18 19:55, Jan Kiszka wrote:
>>> Hi Maksim,
>>>
>>> finally, I actually used the SDK on an ARM target, and it worked nicely! One 
>>> question and one feature request, though:
>>>
>>> I did not do the chroot dance and rather looked for a way to use the cross 
>>> compiler directly. And it /seems/ to work, at least for the trivial case:
>>>
>>> export LD_LIBRARY_PATH=/path-to-sdk/usr/lib/x86_64-linux-gnu/
>>> sdk/usr/bin/arm-linux-gnueabihf-gcc --sysroot /path-to-sdk \
>>>      -o hello hello.c
>>>
>>> Does this make sense, at least for the classic "I need a crosscompiler and 
>>> the corresponding target libs" case? When will it start to break?
> 
> Honestly I always played with chroot and never tried LD_LIBRARY_PATH approach in 
> more complicated case, so I can't say which problems may pop up.

Henning, maybe once worth a try on some of the recent examples we now have (just 
for testing, they are normally built as part of a custom Isar layer).

> 
>> Forgot to state: my host was a SUSE 42.2.
> 
> Nice to hear that it works under SUSE too
> (I only tried sdk on Fedora box).
> 
>>
>>>
>>>
>>> And then I noticed that the deployed SDK image could be a bit slimmer, 
>>> specifically by purging /var/cache/apt prior to packaging. Too lazy now to 
>>> write my own patch. :)
> 
> Got it ;) (I will prepare the patch).

TIA!

BTW, if that direct call model works, we may shrink the SDK archive for that 
purpose even further (as there is no need to have a complete chroot anymore).

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: SDK feedback

[Henning Schild]

Am Wed, 12 Sep 2018 12:15:40 +0200
schrieb Jan Kiszka <jan.kiszka@siemens.com>:

> On 12.09.18 09:42, Maxim Yu. Osipov wrote:
> > Hi Jan,
> > 
> > On 09/11/2018 08:57 PM, Jan Kiszka wrote:  
> >> On 11.09.18 19:55, Jan Kiszka wrote:  
> >>> Hi Maksim,
> >>>
> >>> finally, I actually used the SDK on an ARM target, and it worked
> >>> nicely! One question and one feature request, though:
> >>>
> >>> I did not do the chroot dance and rather looked for a way to use
> >>> the cross compiler directly. And it /seems/ to work, at least for
> >>> the trivial case:
> >>>
> >>> export LD_LIBRARY_PATH=/path-to-sdk/usr/lib/x86_64-linux-gnu/
> >>> sdk/usr/bin/arm-linux-gnueabihf-gcc --sysroot /path-to-sdk \
> >>>      -o hello hello.c
> >>>
> >>> Does this make sense, at least for the classic "I need a
> >>> crosscompiler and the corresponding target libs" case? When will
> >>> it start to break?  
> > 
> > Honestly I always played with chroot and never tried
> > LD_LIBRARY_PATH approach in more complicated case, so I can't say
> > which problems may pop up.  
> 
> Henning, maybe once worth a try on some of the recent examples we now
> have (just for testing, they are normally built as part of a custom
> Isar layer).

People that use that layer found their own solution. They just take the
buildchroot as a sysroot for the cross-compiler of their distro. No
need to have a debian cross compiler or chroot. That has its
limitations, but is also really simple and seems to work well
enough ... so far.

Henning

> >> Forgot to state: my host was a SUSE 42.2.  
> > 
> > Nice to hear that it works under SUSE too
> > (I only tried sdk on Fedora box).

If you chrooted, you used Debian ;).

Henning

> >>  
> >>>
> >>>
> >>> And then I noticed that the deployed SDK image could be a bit
> >>> slimmer, specifically by purging /var/cache/apt prior to
> >>> packaging. Too lazy now to write my own patch. :)  
> > 
> > Got it ;) (I will prepare the patch).  
> 
> TIA!
> 
> BTW, if that direct call model works, we may shrink the SDK archive
> for that purpose even further (as there is no need to have a complete
> chroot anymore).
> 
> Jan
>