Issues and questions regarding PowerPC 32-bits e500v2 tuning

Issues and questions regarding PowerPC 32-bits e500v2 tuning

[Elinor Montmasson]

Hello,

My company is currently interested in building a Yocto distribution for
a PowerPC 32-bit e500v2 platform using the associated tuning available
in OE-Core.
I have a few questions related to the e500v2 tuning in OE-Core.

I understand that PowerPC e500v2 was considered part of a specific architecture
category, PowerPC SPE, which isn't supported anymore in GCC as SPE support
was dropped in GCC 9.1.
In the e500v2 core, the SPE was used as FPU, meaning code for this architecture
can now only be compiled with soft fpu if using active GCC releases.
Do you confirm this analysis?

Building a core-image-minimal with the ppce500v2 tuning in OE-Core doesn't work
out-of-the-box on Yocto Wrynose.
Recipes building with meson (e.g. xorgproto) fail because the do_configure task
runs a "meson-qemuwrapper" binary which fails with SIGILL.
This looks like a floating point configuration problem as adding the tuning
feature "fpu-soft" solves this issue.
This would confirm the lack of SPE support and the need to specify soft fpu
usage or any usage of floating point will result in an execution error.

* Was any testing done for the e500v2 tuning or the e500 tuning?
	* The e500 shares the same SPE specificity.
* Should the e500v2 tuning configuration be considered not up-to-date?
* Is there any plan in updating and testing the e500 and e500v2 tuning
  configurations?
	* Especially, tune-ppce500.inc still enables the "spe" feature,
	  but should encounter the same GCC compatibility problem as the e500v2.

Best regards,
Elinor Montmasson

RE: Issues and questions regarding PowerPC 32-bits e500v2 tuning

[Marko, Peter]

Hello Elinor,

I have already checked SPE on e500 before and can confirm that it needs to be disabled in favor of soft-fpu with newer GCC versions.
It of course dramatically decreases performance, but what can we do...

As usual with Yocto, only the default settings are being tested and untested features slowly bit rot by time.
For now, we don't plan to extend our pipeline to all possible tunes/variations.
So ideally, you should send patches to fix your tune configuration and spin a regular local pipeline with Yocto master to catch if it would break again.

Best Regards,
  Peter

> -----Original Message-----
> From: Elinor Montmasson <elinor.montmasson@savoirfairelinux.com>
> Sent: Wednesday, October 21, 2026 10:35 AM
> To: Freihofer, Adrian (SI B PRO TI EAC CCP) <adrian.freihofer@siemens.com>;
> Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>
> Cc: yocto@lists.yoctoproject.org
> Subject: Issues and questions regarding PowerPC 32-bits e500v2 tuning
> 
> Hello,
> 
> My company is currently interested in building a Yocto distribution for
> a PowerPC 32-bit e500v2 platform using the associated tuning available
> in OE-Core.
> I have a few questions related to the e500v2 tuning in OE-Core.
> 
> I understand that PowerPC e500v2 was considered part of a specific architecture
> category, PowerPC SPE, which isn't supported anymore in GCC as SPE support
> was dropped in GCC 9.1.
> In the e500v2 core, the SPE was used as FPU, meaning code for this architecture
> can now only be compiled with soft fpu if using active GCC releases.
> Do you confirm this analysis?
> 
> Building a core-image-minimal with the ppce500v2 tuning in OE-Core doesn't
> work
> out-of-the-box on Yocto Wrynose.
> Recipes building with meson (e.g. xorgproto) fail because the do_configure task
> runs a "meson-qemuwrapper" binary which fails with SIGILL.
> This looks like a floating point configuration problem as adding the tuning
> feature "fpu-soft" solves this issue.
> This would confirm the lack of SPE support and the need to specify soft fpu
> usage or any usage of floating point will result in an execution error.
> 
> * Was any testing done for the e500v2 tuning or the e500 tuning?
> 	* The e500 shares the same SPE specificity.
> * Should the e500v2 tuning configuration be considered not up-to-date?
> * Is there any plan in updating and testing the e500 and e500v2 tuning
>   configurations?
> 	* Especially, tune-ppce500.inc still enables the "spe" feature,
> 	  but should encounter the same GCC compatibility problem as the
> e500v2.
> 
> Best regards,
> Elinor Montmasson

Re: Issues and questions regarding PowerPC 32-bits e500v2 tuning

[Elinor Montmasson]

Hello Peter,

----- Original Message -----
> From: "peter marko" <Peter.Marko@siemens.com>
> To: "Elinor Montmasson" <elinor.montmasson@savoirfairelinux.com>, "adrian freihofer" <adrian.freihofer@siemens.com>
> Cc: "yocto" <yocto@lists.yoctoproject.org>
> Sent: Wednesday, 21 October, 2026 15:50:22
> Subject: RE: Issues and questions regarding PowerPC 32-bits e500v2 tuning

> Hello Elinor,
> 
> I have already checked SPE on e500 before and can confirm that it needs to be
> disabled in favor of soft-fpu with newer GCC versions.
> It of course dramatically decreases performance, but what can we do...
> 
> As usual with Yocto, only the default settings are being tested and untested
> features slowly bit rot by time.
> For now, we don't plan to extend our pipeline to all possible tunes/variations.
> So ideally, you should send patches to fix your tune configuration and spin a
> regular local pipeline with Yocto master to catch if it would break again.
> 
> Best Regards,
>  Peter

Ok, thank you for your answer, at least it confirms my analysis.

Because GCC is not an option for SPE support, I am considering using
the LLVM/Clang toolchain through meta-clang, as it seems to support
PowerPC SPE.
I know that some specific recipes will require building with GCC anyway,
in that case fpu-soft will be enabled, but most of the distribution
could build with clang.

Is it something you have tested?

Best regards,
Elinor Montmasson

RE: Issues and questions regarding PowerPC 32-bits e500v2 tuning

[Marko, Peter]

> -----Original Message-----
> From: Elinor Montmasson <elinor.montmasson@savoirfairelinux.com>
> Sent: Wednesday, October 21, 2026 5:02 PM
> To: Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>
> Cc: Freihofer, Adrian (SI B PRO TI EAC CCP) <adrian.freihofer@siemens.com>;
> yocto <yocto@lists.yoctoproject.org>
> Subject: Re: Issues and questions regarding PowerPC 32-bits e500v2 tuning
> 
> Hello Peter,
> 
> ----- Original Message -----
> > From: "peter marko" <Peter.Marko@siemens.com>
> > To: "Elinor Montmasson" <elinor.montmasson@savoirfairelinux.com>, "adrian
> freihofer" <adrian.freihofer@siemens.com>
> > Cc: "yocto" <yocto@lists.yoctoproject.org>
> > Sent: Wednesday, 21 October, 2026 15:50:22
> > Subject: RE: Issues and questions regarding PowerPC 32-bits e500v2 tuning
> 
> > Hello Elinor,
> >
> > I have already checked SPE on e500 before and can confirm that it needs to be
> > disabled in favor of soft-fpu with newer GCC versions.
> > It of course dramatically decreases performance, but what can we do...
> >
> > As usual with Yocto, only the default settings are being tested and untested
> > features slowly bit rot by time.
> > For now, we don't plan to extend our pipeline to all possible tunes/variations.
> > So ideally, you should send patches to fix your tune configuration and spin a
> > regular local pipeline with Yocto master to catch if it would break again.
> >
> > Best Regards,
> >  Peter
> 
> Ok, thank you for your answer, at least it confirms my analysis.
> 
> Because GCC is not an option for SPE support, I am considering using
> the LLVM/Clang toolchain through meta-clang, as it seems to support
> PowerPC SPE.
> I know that some specific recipes will require building with GCC anyway,
> in that case fpu-soft will be enabled, but most of the distribution
> could build with clang.
> 
> Is it something you have tested?

This is an interesting idea well worth trying, but afaik we have not tried that.
Note that I was only involved in discussions with other projects, I personally have never built/used e500.

Peter

> 
> Best regards,
> Elinor Montmasson

Re: Issues and questions regarding PowerPC 32-bits e500v2 tuning

[Freihofer, Adrian]

On Thu, 2026-10-22 at 08:21 +0000, Marko, Peter (FT D EU SK BFS1)
wrote:
> 
> 
> > -----Original Message-----
> > From: Elinor Montmasson <elinor.montmasson@savoirfairelinux.com>
> > Sent: Wednesday, October 21, 2026 5:02 PM
> > To: Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>
> > Cc: Freihofer, Adrian (SI B PRO TI EAC CCP)
> > <adrian.freihofer@siemens.com>;
> > yocto <yocto@lists.yoctoproject.org>
> > Subject: Re: Issues and questions regarding PowerPC 32-bits e500v2
> > tuning
> > 
> > Hello Peter,
> > 
> > ----- Original Message -----
> > > From: "peter marko" <Peter.Marko@siemens.com>
> > > To: "Elinor Montmasson" <elinor.montmasson@savoirfairelinux.com>,
> > > "adrian
> > freihofer" <adrian.freihofer@siemens.com>
> > > Cc: "yocto" <yocto@lists.yoctoproject.org>
> > > Sent: Wednesday, 21 October, 2026 15:50:22
> > > Subject: RE: Issues and questions regarding PowerPC 32-bits
> > > e500v2 tuning
> > 
> > > Hello Elinor,
> > > 
> > > I have already checked SPE on e500 before and can confirm that it
> > > needs to be
> > > disabled in favor of soft-fpu with newer GCC versions.
> > > It of course dramatically decreases performance, but what can we
> > > do...
> > > 
> > > As usual with Yocto, only the default settings are being tested
> > > and untested
> > > features slowly bit rot by time.
> > > For now, we don't plan to extend our pipeline to all possible
> > > tunes/variations.
> > > So ideally, you should send patches to fix your tune
> > > configuration and spin a
> > > regular local pipeline with Yocto master to catch if it would
> > > break again.
> > > 
> > > Best Regards,
> > >  Peter
> > 
> > Ok, thank you for your answer, at least it confirms my analysis.
> > 
> > Because GCC is not an option for SPE support, I am considering
> > using
> > the LLVM/Clang toolchain through meta-clang, as it seems to support
> > PowerPC SPE.
> > I know that some specific recipes will require building with GCC
> > anyway,
> > in that case fpu-soft will be enabled, but most of the distribution
> > could build with clang.
> > 
> > Is it something you have tested?
> 
> This is an interesting idea well worth trying, but afaik we have not
> tried that.
> Note that I was only involved in discussions with other projects, I
> personally have never built/used e500.

Hi Elinor

I remember the times when I was working with a MPC5200. Quite a few
years ago :-).

If you can mix binaries built with different floating point
implementations depends on the details of the CPU architecture, at
least. We had some discussions related to ARM 32 a few years ago. I
just remember that "it depends on the details".

With wrynose there is now a TOOLCHAIN variable which can be set to
clang globally. But it depends on what you need if a build without gcc
is possible or not. For example, there is a patchset which fixes glibc
for building with clang (around 50 patches from ARM) somewhere around.
With musl it should work as well. Not sure this would allow you to go
with clang only for your use case.

There are also some discussions with maintaining some LTS branches like
dunfell for longer than 4 years unofficially by users who need that.

Just some alternative ideas.

Regards,
Adrian

> 
> Peter
> 
> > 
> > Best regards,
> > Elinor Montmasson

Re: [yocto] Issues and questions regarding PowerPC 32-bits e500v2 tuning

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 5664 bytes --]

On Thu, Oct 22, 2026 at 2:27 AM Adrian Freihofer via lists.yoctoproject.org
<adrian.freihofer=siemens.com@lists.yoctoproject.org> wrote:

> On Thu, 2026-10-22 at 08:21 +0000, Marko, Peter (FT D EU SK BFS1)
> wrote:
> >
> >
> > > -----Original Message-----
> > > From: Elinor Montmasson <elinor.montmasson@savoirfairelinux.com>
> > > Sent: Wednesday, October 21, 2026 5:02 PM
> > > To: Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>
> > > Cc: Freihofer, Adrian (SI B PRO TI EAC CCP)
> > > <adrian.freihofer@siemens.com>;
> > > yocto <yocto@lists.yoctoproject.org>
> > > Subject: Re: Issues and questions regarding PowerPC 32-bits e500v2
> > > tuning
> > >
> > > Hello Peter,
> > >
> > > ----- Original Message -----
> > > > From: "peter marko" <Peter.Marko@siemens.com>
> > > > To: "Elinor Montmasson" <elinor.montmasson@savoirfairelinux.com>,
> > > > "adrian
> > > freihofer" <adrian.freihofer@siemens.com>
> > > > Cc: "yocto" <yocto@lists.yoctoproject.org>
> > > > Sent: Wednesday, 21 October, 2026 15:50:22
> > > > Subject: RE: Issues and questions regarding PowerPC 32-bits
> > > > e500v2 tuning
> > >
> > > > Hello Elinor,
> > > >
> > > > I have already checked SPE on e500 before and can confirm that it
> > > > needs to be
> > > > disabled in favor of soft-fpu with newer GCC versions.
> > > > It of course dramatically decreases performance, but what can we
> > > > do...
> > > >
> > > > As usual with Yocto, only the default settings are being tested
> > > > and untested
> > > > features slowly bit rot by time.
> > > > For now, we don't plan to extend our pipeline to all possible
> > > > tunes/variations.
> > > > So ideally, you should send patches to fix your tune
> > > > configuration and spin a
> > > > regular local pipeline with Yocto master to catch if it would
> > > > break again.
> > > >
> > > > Best Regards,
> > > >  Peter
> > >
> > > Ok, thank you for your answer, at least it confirms my analysis.
> > >
> > > Because GCC is not an option for SPE support, I am considering
> > > using
> > > the LLVM/Clang toolchain through meta-clang, as it seems to support
> > > PowerPC SPE.
> > > I know that some specific recipes will require building with GCC
> > > anyway,
> > > in that case fpu-soft will be enabled, but most of the distribution
> > > could build with clang.
> > >
> > > Is it something you have tested?
> >
> > This is an interesting idea well worth trying, but afaik we have not
> > tried that.
> > Note that I was only involved in discussions with other projects, I
> > personally have never built/used e500.
>
> Hi Elinor
>
> I remember the times when I was working with a MPC5200. Quite a few
> years ago :-).
>
> If you can mix binaries built with different floating point
> implementations depends on the details of the CPU architecture, at
> least. We had some discussions related to ARM 32 a few years ago. I
> just remember that "it depends on the details".
>
> With wrynose there is now a TOOLCHAIN variable which can be set to
> clang globally. But it depends on what you need if a build without gcc
> is possible or not. For example, there is a patchset which fixes glibc
> for building with clang (around 50 patches from ARM) somewhere around.
> With musl it should work as well. Not sure this would allow you to go
> with clang only for your use case.
>
> There are also some discussions with maintaining some LTS branches like
> dunfell for longer than 4 years unofficially by users who need that.
>
> Just some alternative ideas.
>
>
GCC dropped SPE in 9.1 timeframe, so soft-float is the only option. however
another
issue is that glibc also dropped it starting 2.30 release, so only option
is using musl since
it does support single float (-sf)  abi on ppc.

I added  0019-Re-introduce-spe-commandline-options.patch, back then to keep
qemuppc working, it simply made gcc to accept  -mabi=spe -mspe
-mfloat-gprs=double
which are passed from tune-ppce500v2.inc, it then ignores them and falls
back to
classic hard-float FPU instructions, e500v2 has no classic FPU, so the
binaries crash with SIGILL
is no surprise.  tune-ppce500.inc has the same problem. It has the same spe
feature with
-mfloat-gprs=single.
a performance-compromised fix is to make these tunes use fpu-soft and drop
spe

Using clang is not going to work out of box either, while it does support
SPE it does have
some things to take care of e.g. -mfloat-gprs=double is not supported. it
also will reject
 linux-gnuspe and linux-muslspe triples that OE uses. it needs something
like  powerpcspe-*-*
or patching llvm sources to do what OE has done in past.

Some recipes with GCC + fpu-soft, the rest with clang + SPE combo has an
ABI problem.
Ordinary calls and returns are compatible, since both pass doubles in pairs
of general registers.
The trouble is mixing the two in one process: a libgcc built for soft-float
sets the FP environment
differently from SPE code.

Dunfell is not a way to keep SPE; only warrior or older is.


> Regards,
> Adrian
>
> >
> > Peter
> >
> > >
> > > Best regards,
> > > Elinor Montmasson
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> You automatically follow any topics you start or reply to.
> View/Reply Online (#66780):
> https://lists.yoctoproject.org/g/yocto/message/66780
> Mute This Topic: https://lists.yoctoproject.org/mt/121863659/1997914
> Group Owner: yocto+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [
> raj.khem@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

[-- Attachment #2: Type: text/html, Size: 8577 bytes --]

Re: [yocto] Issues and questions regarding PowerPC 32-bits e500v2 tuning

[Elinor Montmasson]

----- Original Message -----
> From: "Khem Raj" <raj.khem@gmail.com>
> To: "yocto" <yocto@lists.yoctoproject.org>, "adrian freihofer" <adrian.freihofer@siemens.com>
> Cc: "Elinor Montmasson" <elinor.montmasson@savoirfairelinux.com>
> Sent: Thursday, 22 October, 2026 22:37:25
> Subject: Re: [yocto] Issues and questions regarding PowerPC 32-bits e500v2 tuning

>> On Thu, Oct 22, 2026 at 2:27 AM Adrian Freihofer via [
>> http://lists.yoctoproject.org/ | lists.yoctoproject.org ] <adrian.freihofer= [
>> mailto:siemens.com@lists.yoctoproject.org | siemens.com@lists.yoctoproject.org
>> ] > wrote:

>> Hi Elinor

>> I remember the times when I was working with a MPC5200. Quite a few
>> years ago :-).

>> If you can mix binaries built with different floating point
>> implementations depends on the details of the CPU architecture, at
>> least. We had some discussions related to ARM 32 a few years ago. I
>> just remember that "it depends on the details".

>> With wrynose there is now a TOOLCHAIN variable which can be set to
>> clang globally. But it depends on what you need if a build without gcc
>> is possible or not. For example, there is a patchset which fixes glibc
>> for building with clang (around 50 patches from ARM) somewhere around.
>> With musl it should work as well. Not sure this would allow you to go
>> with clang only for your use case.

>> There are also some discussions with maintaining some LTS branches like
>> dunfell for longer than 4 years unofficially by users who need that.

>> Just some alternative ideas.

> GCC dropped SPE in 9.1 timeframe, so soft-float is the only option. however
> another
> issue is that glibc also dropped it starting 2.30 release, so only option is
> using musl since
> it does support single float (-sf) abi on ppc.

Yes good point thanks

> I added 0019-Re-introduce-spe-commandline-options.patch, back then to keep
> qemuppc working, it simply made gcc to accept -mabi=spe -mspe
> -mfloat-gprs=double
> which are passed from tune-ppce500v2.inc, it then ignores them and falls back to
> classic hard-float FPU instructions, e500v2 has no classic FPU, so the binaries
> crash with SIGILL
> is no surprise. tune-ppce500.inc has the same problem. It has the same spe
> feature with
> -mfloat-gprs=single.
> a performance-compromised fix is to make these tunes use fpu-soft and drop spe

> Using clang is not going to work out of box either, while it does support SPE it
> does have
> some things to take care of e.g. -mfloat-gprs=double is not supported.

Do you know if an equivalent option or options exist with clang for this?
Or if it just not relevant with clang?

> it also will reject
> linux-gnuspe and linux-muslspe triples that OE uses. it needs something like
> powerpcspe-*-*
> or patching llvm sources to do what OE has done in past.

> Some recipes with GCC + fpu-soft, the rest with clang + SPE combo has an ABI
> problem.
> Ordinary calls and returns are compatible, since both pass doubles in pairs of
> general registers.
> The trouble is mixing the two in one process: a libgcc built for soft-float sets
> the FP environment
> differently from SPE code.

I see
So does it means that for a given application/process, the floating point
support (soft or SPE here) must be the same for the runtime used,
the dynamic libraries used and the application itself,
to avoid any ABI compatibility problem?

In that case, I suppose two compiler runtime may be installed,
compiled with their respective compiler?
* libgcc for GCC + fpu-soft compiled programs
* llvm runtime for clang + SPE compiled programs

But then the ABI compatibility constraint will create complexity for
compiling and installing shared libraries.

> Dunfell is not a way to keep SPE; only warrior or older is.


Best regards,
Elinor Montmasson

Re: [yocto] Issues and questions regarding PowerPC 32-bits e500v2 tuning

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 4324 bytes --]

On Fri, Oct 23, 2026 at 1:27 AM Elinor Montmasson <
elinor.montmasson@savoirfairelinux.com> wrote:

> ----- Original Message -----
> > From: "Khem Raj" <raj.khem@gmail.com>
> > To: "yocto" <yocto@lists.yoctoproject.org>, "adrian freihofer" <
> adrian.freihofer@siemens.com>
> > Cc: "Elinor Montmasson" <elinor.montmasson@savoirfairelinux.com>
> > Sent: Thursday, 22 October, 2026 22:37:25
> > Subject: Re: [yocto] Issues and questions regarding PowerPC 32-bits
> e500v2 tuning
>
> >> On Thu, Oct 22, 2026 at 2:27 AM Adrian Freihofer via [
> >> http://lists.yoctoproject.org/ | lists.yoctoproject.org ]
> <adrian.freihofer= [
> >> mailto:siemens.com@lists.yoctoproject.org |
> siemens.com@lists.yoctoproject.org
> >> ] > wrote:
>
> >> Hi Elinor
>
> >> I remember the times when I was working with a MPC5200. Quite a few
> >> years ago :-).
>
> >> If you can mix binaries built with different floating point
> >> implementations depends on the details of the CPU architecture, at
> >> least. We had some discussions related to ARM 32 a few years ago. I
> >> just remember that "it depends on the details".
>
> >> With wrynose there is now a TOOLCHAIN variable which can be set to
> >> clang globally. But it depends on what you need if a build without gcc
> >> is possible or not. For example, there is a patchset which fixes glibc
> >> for building with clang (around 50 patches from ARM) somewhere around.
> >> With musl it should work as well. Not sure this would allow you to go
> >> with clang only for your use case.
>
> >> There are also some discussions with maintaining some LTS branches like
> >> dunfell for longer than 4 years unofficially by users who need that.
>
> >> Just some alternative ideas.
>
> > GCC dropped SPE in 9.1 timeframe, so soft-float is the only option.
> however
> > another
> > issue is that glibc also dropped it starting 2.30 release, so only
> option is
> > using musl since
> > it does support single float (-sf) abi on ppc.
>
> Yes good point thanks
>
> > I added 0019-Re-introduce-spe-commandline-options.patch, back then to
> keep
> > qemuppc working, it simply made gcc to accept -mabi=spe -mspe
> > -mfloat-gprs=double
> > which are passed from tune-ppce500v2.inc, it then ignores them and falls
> back to
> > classic hard-float FPU instructions, e500v2 has no classic FPU, so the
> binaries
> > crash with SIGILL
> > is no surprise. tune-ppce500.inc has the same problem. It has the same
> spe
> > feature with
> > -mfloat-gprs=single.
> > a performance-compromised fix is to make these tunes use fpu-soft and
> drop spe
>
> > Using clang is not going to work out of box either, while it does
> support SPE it
> > does have
> > some things to take care of e.g. -mfloat-gprs=double is not supported.
>
> Do you know if an equivalent option or options exist with clang for this?
> Or if it just not relevant with clang?
>

-mspe for -mfloat-gprs=double
-mspe -mefpu2 for -mfloat-gprs=single

>
> > it also will reject
> > linux-gnuspe and linux-muslspe triples that OE uses. it needs something
> like
> > powerpcspe-*-*
> > or patching llvm sources to do what OE has done in past.
>
> > Some recipes with GCC + fpu-soft, the rest with clang + SPE combo has an
> ABI
> > problem.
> > Ordinary calls and returns are compatible, since both pass doubles in
> pairs of
> > general registers.
> > The trouble is mixing the two in one process: a libgcc built for
> soft-float sets
> > the FP environment
> > differently from SPE code.
>
> I see
> So does it means that for a given application/process, the floating point
> support (soft or SPE here) must be the same for the runtime used,
> the dynamic libraries used and the application itself,
> to avoid any ABI compatibility problem?
>

yes

>
> In that case, I suppose two compiler runtime may be installed,
> compiled with their respective compiler?
> * libgcc for GCC + fpu-soft compiled programs
> * llvm runtime for clang + SPE compiled programs
>
> But then the ABI compatibility constraint will create complexity for
> compiling and installing shared libraries.
>

right thats what i think too

>
> > Dunfell is not a way to keep SPE; only warrior or older is.
>
>
> Best regards,
> Elinor Montmasson
>

[-- Attachment #2: Type: text/html, Size: 6160 bytes --]