[Buildroot] BuildRoot cannot build powerpc64

[Buildroot] BuildRoot cannot build powerpc64

[ANDY KENNEDY]

All,

I just downloaded 2016_08rc-1 and attempted to build an RFS for the
T-series PowerPC parts, which, I assume, are powerpc64 and e5500.  In
doing so, after I select powerpc64 I cannot select any library for the
toolchain as all of the config dependencies appear to be excluding
powerpc64 in the options.

Is this by design or oversight?

Thanks,
Andy

[Buildroot] BuildRoot cannot build powerpc64

[Ricardo Martincoski]

Hi Andy,

On Tue, Aug 16, 2016 at 07:43 PM, ANDY KENNEDY <ANDY.KENNEDY@adtran.com> wrote:

> All,
> 
> I just downloaded 2016_08rc-1 and attempted to build an RFS for the
> T-series PowerPC parts, which, I assume, are powerpc64 and e5500.  In
> doing so, after I select powerpc64 I cannot select any library for the
> toolchain as all of the config dependencies appear to be excluding
> powerpc64 in the options.
> 
> Is this by design or oversight?

With Ubuntu 16.04 I can reproduce the behavior only after selecting static libs.

BR2_powerpc64=y
BR2_powerpc_e5500=y
BR2_STATIC_LIBS=y

Maybe you can unblock your work if static build is not a strict requirement.

Regards,
Ricardo

[Buildroot] BuildRoot cannot build powerpc64

[ANDY KENNEDY]

Thanks for the info Ricardo!

> 
> Hi Andy,
> 
> On Tue, Aug 16, 2016 at 07:43 PM, ANDY KENNEDY <ANDY.KENNEDY@adtran.com> wrote:
> 
> > All,
> >
> > I just downloaded 2016_08rc-1 and attempted to build an RFS for the
> > T-series PowerPC parts, which, I assume, are powerpc64 and e5500.  In
> > doing so, after I select powerpc64 I cannot select any library for the
> > toolchain as all of the config dependencies appear to be excluding
> > powerpc64 in the options.
> >
> > Is this by design or oversight?
> 
> With Ubuntu 16.04 I can reproduce the behavior only after selecting static libs.
> 
> BR2_powerpc64=y
> BR2_powerpc_e5500=y
> BR2_STATIC_LIBS=y
> 
> Maybe you can unblock your work if static build is not a strict requirement.

Our RFS we like to have static, so that we can throw libs into
the system @ runtime without breaking our stable RFS.

Based upon your e-mail, I dropped into the uclibc dependencies
|| BR2_powerpc64, which made it selectable.  Problem is that
it wouldn?t build.  My guess is that the T-series parts haven't
been added to uClibC-ng yet, which is why it isn't selectable.

Thus, the answer to my question is "it is by design".

Thanks for the help, though!

Andy

[Buildroot] BuildRoot cannot build powerpc64

[Thomas Petazzoni]

Hello,

On Wed, 17 Aug 2016 15:33:30 +0000, ANDY KENNEDY wrote:

> Our RFS we like to have static, so that we can throw libs into
> the system @ runtime without breaking our stable RFS.
> 
> Based upon your e-mail, I dropped into the uclibc dependencies
> || BR2_powerpc64, which made it selectable.  Problem is that
> it wouldn?t build.  My guess is that the T-series parts haven't
> been added to uClibC-ng yet, which is why it isn't selectable.
> 
> Thus, the answer to my question is "it is by design".

The only C library that supports PowerPC64 today is glibc.

But glibc does not support static linking.

Hence there is no solution to do a statically linked rootfs on
PowerPC64 today.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] BuildRoot cannot build powerpc64

[Waldemar Brodkorb]

Hi,
Thomas Petazzoni wrote,

> Hello,
> 
> On Wed, 17 Aug 2016 15:33:30 +0000, ANDY KENNEDY wrote:
> 
> > Our RFS we like to have static, so that we can throw libs into
> > the system @ runtime without breaking our stable RFS.
> > 
> > Based upon your e-mail, I dropped into the uclibc dependencies
> > || BR2_powerpc64, which made it selectable.  Problem is that
> > it wouldn?t build.  My guess is that the T-series parts haven't
> > been added to uClibC-ng yet, which is why it isn't selectable.
> > 
> > Thus, the answer to my question is "it is by design".
> 
> The only C library that supports PowerPC64 today is glibc.
> 
> But glibc does not support static linking.
> 
> Hence there is no solution to do a statically linked rootfs on
> PowerPC64 today.

Latest musl release supports ppc64.
I will sent a patch to allow to build it.

best regards
 Waldemar

[Buildroot] BuildRoot cannot build powerpc64

[Arnout Vandecappelle]

On 17-08-16 19:37, Thomas Petazzoni wrote:
> Hello,
> 
> On Wed, 17 Aug 2016 15:33:30 +0000, ANDY KENNEDY wrote:
> 
>> Our RFS we like to have static, so that we can throw libs into
>> the system @ runtime without breaking our stable RFS.
>>
>> Based upon your e-mail, I dropped into the uclibc dependencies
>> || BR2_powerpc64, which made it selectable.  Problem is that
>> it wouldn?t build.  My guess is that the T-series parts haven't
>> been added to uClibC-ng yet, which is why it isn't selectable.
>>
>> Thus, the answer to my question is "it is by design".
> 
> The only C library that supports PowerPC64 today is glibc.
> 
> But glibc does not support static linking.
> 
> Hence there is no solution to do a statically linked rootfs on
> PowerPC64 today.

 Perhaps we should remove the static/shared libs options to the toolchain menu,
and make them depend on the libc choice rather than the other way round. That
way, we're sure that we never run into such impossible situations.

 Actually also some other options are more fitting in the toolchain menu IMHO,
like debug/optimization options and SSP.

 Regards,
 Arnout


-- 
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:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] BuildRoot cannot build powerpc64

[Thomas Petazzoni]

Hello,

On Thu, 18 Aug 2016 20:02:31 +0200, Arnout Vandecappelle wrote:

> > The only C library that supports PowerPC64 today is glibc.
> > 
> > But glibc does not support static linking.
> > 
> > Hence there is no solution to do a statically linked rootfs on
> > PowerPC64 today.  
> 
>  Perhaps we should remove the static/shared libs options to the toolchain menu,
> and make them depend on the libc choice rather than the other way round. That
> way, we're sure that we never run into such impossible situations.
> 
>  Actually also some other options are more fitting in the toolchain menu IMHO,
> like debug/optimization options and SSP.

I personally don't like this, and instead would like to keep separated
the options that affect the build of all components (SSP or not,
debug/optimization, shared/static) from the options that configure the
toolchain itself.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] BuildRoot cannot build powerpc64

[Khem Raj]

> On Aug 18, 2016, at 11:02 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
> 
> On 17-08-16 19:37, Thomas Petazzoni wrote:
>> Hello,
>> 
>> On Wed, 17 Aug 2016 15:33:30 +0000, ANDY KENNEDY wrote:
>> 
>>> Our RFS we like to have static, so that we can throw libs into
>>> the system @ runtime without breaking our stable RFS.
>>> 
>>> Based upon your e-mail, I dropped into the uclibc dependencies
>>> || BR2_powerpc64, which made it selectable.  Problem is that
>>> it wouldn?t build.  My guess is that the T-series parts haven't
>>> been added to uClibC-ng yet, which is why it isn't selectable.
>>> 
>>> Thus, the answer to my question is "it is by design".
>> 
>> The only C library that supports PowerPC64 today is glibc.
>> 
>> But glibc does not support static linking.
>> 
>> Hence there is no solution to do a statically linked rootfs on
>> PowerPC64 today.
> 
> Perhaps we should remove the static/shared libs options to the toolchain menu,
> and make them depend on the libc choice rather than the other way round. That
> way, we're sure that we never run into such impossible situations.

static linking and dynamic linking needs to know if C library supports it
and architecture. It  should not be a toolchain option its a runtime env option
semantically.

> 
> Actually also some other options are more fitting in the toolchain menu IMHO,
> like debug/optimization options and SSP.

Those are also not toolchain related imo they are global in nature though

> 
> Regards,
> Arnout
> 
> 
> --
> 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:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160818/7aac18ca/attachment.asc>

[Buildroot] BuildRoot cannot build powerpc64

[Arnout Vandecappelle]

On 18-08-16 23:18, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu, 18 Aug 2016 20:02:31 +0200, Arnout Vandecappelle wrote:
> 
>>> The only C library that supports PowerPC64 today is glibc.
>>>
>>> But glibc does not support static linking.
>>>
>>> Hence there is no solution to do a statically linked rootfs on
>>> PowerPC64 today.  
>>
>>  Perhaps we should remove the static/shared libs options to the toolchain menu,
>> and make them depend on the libc choice rather than the other way round. That
>> way, we're sure that we never run into such impossible situations.
>>
>>  Actually also some other options are more fitting in the toolchain menu IMHO,
>> like debug/optimization options and SSP.
> 
> I personally don't like this, and instead would like to keep separated
> the options that affect the build of all components (SSP or not,
> debug/optimization, shared/static) from the options that configure the
> toolchain itself.

 OK, fair enough.

 Actually, I noticed now that SSP in the build menu already depends on the
toolchain choices. So perhaps we should move the build options below the
toolchain, and make the static/shared libs options depend on the toolchain as well.

 That leaves us just with the awkward headers-same-as-kernel forward dependency.

 Regards,
 Arnout


-- 
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:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] BuildRoot cannot build powerpc64

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hi,

 >>> Actually also some other options are more fitting in the toolchain menu IMHO,
 >>> like debug/optimization options and SSP.
 >> 
 >> I personally don't like this, and instead would like to keep separated
 >> the options that affect the build of all components (SSP or not,
 >> debug/optimization, shared/static) from the options that configure the
 >> toolchain itself.

 >  OK, fair enough.

 >  Actually, I noticed now that SSP in the build menu already depends on the
 > toolchain choices. So perhaps we should move the build options below the
 > toolchain, and make the static/shared libs options depend on the toolchain as well.

Yes, perhaps that is less confusing. It isn't perfect as the build
options are more general than toolchain, but the current setup where
people have to jump back/forth between the build options and toolchain
menus also isn't very nice.

 >  That leaves us just with the awkward headers-same-as-kernel forward dependency.

Yeah :/

-- 
Bye, Peter Korsgaard