Debian Bug report logs - #701561
ioquake3: FTBFS on powerpcspe

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Roland Stigge <stigge@antcom.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: ioquake3: FTBFS on powerpcspe

Date: Sun, 24 Feb 2013 14:19:04 +0100

[Message part 1 (text/plain, inline)]

Package: ioquake3
Version: 1.36+svn2287-1
Severity: wishlist
Tags: patch sid
User: debian-powerpcspe@breakpoint.cc
Usertags: powerpcspe

Hi,

ioquake3 currently FTBFS on powerpcspe[1] like this:

[...]
make[4]: Entering directory `/«BUILDDIR»/ioquake3-1.36+svn2287'
cc  -DDEDICATED -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -fsigned-char -DWITH_OPENARENA -D_FORTIFY_SOURCE=2 -Wall -fno-strict-aliasing -Wimplicit -Wstrict-prototypes -pipe -DUSE_ICON -maltivec -DDEFAULT_BASEDIR=\"/usr/lib/ioquake3\" -DPRODUCT_VERSION=\"1.36+svn2287-1/Debian\" -Wformat=2 -Wno-format-zero-length -Wformat-security -Wno-format-nonliteral -Wstrict-aliasing=2 -Wmissing-format-attribute -Wdisabled-optimization -Werror-implicit-function-declaration -MMD -DUSE_VOIP -DNDEBUG -O3 -funroll-loops -fomit-frame-pointer -ffast-math -o build/ded/sv_bot.o -c code/server/sv_bot.c
code/server/sv_bot.c:1:0: error: AltiVec and E500 instructions cannot coexist
make[4]: *** [build/ded/sv_bot.o] Error 1
[...]

This is due to PowerPC/Altivec code that doesn't work on powerpcspe.

Attaching a patch that fixes this by omitting the respective instructions
on powerpcspe.

Thanks,

Roland


[1] http://wiki.debian.org/PowerPCSPEPort


-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.7.0 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash

[ioquake3.patch (text/x-diff, attachment)]

Message #10 received at 701561@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Roland Stigge <stigge@antcom.de>, 701561@bugs.debian.org

Subject: Re: Bug#701561: ioquake3: FTBFS on powerpcspe

Date: Mon, 25 Feb 2013 10:37:43 +0000

On 24/02/13 13:19, Roland Stigge wrote:
> This is due to PowerPC/Altivec code that doesn't work on powerpcspe.
> 
> Attaching a patch that fixes this by omitting the respective instructions
> on powerpcspe.

Do the resulting binaries work on non-Altivec PowerPCs, or have you just
build-tested it? I'd rather have ioquake3 build on fewer architectures
than have it build, but not work. I dimly remember something about the
PowerPC JIT emitting Altivec instructions?

Because the virtual machine is involved, the way to test it would be to
either use quake3 and game-data-packager (you'll need baseq3/pak0.pk3
from a retail Quake III Arena CD-ROM or installation - I'm told the
Steam version is sufficient), or to test with OpenArena and replace
Debian's altered baseoa/pak0.pk3, baseoa/pak6-patch083.pk3 and
baseoa/pak6-patch-088.pk3 with the ones supplied by upstream.

Debian's OpenArena uses native code instead of the virtual machine, for
DFSG reasons - we have a Free interpreter and JIT for the VM bytecode,
but no Free compiler - which is why you'd have to replace that data.

I don't have a usable PowerPC, so I can't test there (and both my
non-working PPCs have Altivec, so they're not much use for this
particular bug either).

> +ifeq ($(DEB_HOST_ARCH),powerpcspe)
> +NO_ALTIVEC := 1
> +else
> +NO_ALTIVEC := 0
> +endif

In principle we ought to do this on all PowerPC architectures - Debian's
powerpc target is a baseline non-Altivec PowerPC (in the same way that
Debian i386 supports any CPU >= i486, and cannot assume MMX or SSE) -
but since I can't test ioquake3 on PowerPC, I'd rather keep the current
state (which *someone* has tested, upstream), rather than gain
compatibility with really old PPCs at the cost of potentially breaking
*all* PPCs.

> +#if defined(Q3_VM) || defined (__NO_FPRS__)

I'm pretty sure this is wrong: it's using the Q3 virtual machine
code-path. It would be better to knock out or modify the
"defined(__VEC__)" check further down the same file, or maybe define
C_ONLY? (This might uncover bugs where upstream have assumed that idppc
implies Altivec - idppc_altivec is the macro that's meant to signal
Altivec.)

Regards,
    S

Message #15 received at 701561@bugs.debian.org (full text, mbox, reply):

From: Roland Stigge <stigge@antcom.de>

To: Simon McVittie <smcv@debian.org>

Cc: 701561@bugs.debian.org

Subject: Re: Bug#701561: ioquake3: FTBFS on powerpcspe

Date: Mon, 25 Feb 2013 11:59:38 +0100

Hi,

On 02/25/2013 11:37 AM, Simon McVittie wrote:
> On 24/02/13 13:19, Roland Stigge wrote:
>> This is due to PowerPC/Altivec code that doesn't work on powerpcspe.
>>
>> Attaching a patch that fixes this by omitting the respective instructions
>> on powerpcspe.
> 
> Do the resulting binaries work on non-Altivec PowerPCs, or have you just
> build-tested it?

I built it, and checked that the /usr/lib/ioquake3/ioquake3 executable
starts (pak0.pk3 is missing, though).

> I'd rather have ioquake3 build on fewer architectures
> than have it build, but not work.

Removing powerpcspe from the supported Debian arches would be fine. Just
please don't tell "linux-any" if you don't mean it.

> Because the virtual machine is involved, the way to test it would be to
> either use quake3 and game-data-packager (you'll need baseq3/pak0.pk3
> from a retail Quake III Arena CD-ROM or installation

Don't have this one, unfortunately. I guess it's non-free? ;-)

Roland

Message #22 received at 701561@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Roland Stigge <stigge@antcom.de>, 701561@bugs.debian.org

Subject: Re: Bug#701561: ioquake3: FTBFS on powerpcspe

Date: Mon, 20 May 2013 00:31:31 +0100

On Mon, 25 Feb 2013 at 11:59:38 +0100, Roland Stigge wrote:
> On 02/25/2013 11:37 AM, Simon McVittie wrote:
> > Because the virtual machine is involved, the way to test it would be to
> > either use quake3 and game-data-packager (you'll need baseq3/pak0.pk3
> > from a retail Quake III Arena CD-ROM or installation
> 
> Don't have this one, unfortunately. I guess it's non-free? ;-)

Yes, Quake III Arena is not freely downloadable. If you don't own a copy
of Quake III Arena, the other way to test with the bytecode would be:

* Install Debian's openarena package

* Download http://www.pseudorandom.co.uk/~smcv/oa088upstream/vms.pk3
  and put it in ~/.openarena/oa088upstream/vms.pk3
  (it contains bytecode executables for the UI, server-side game and
  client-side game - we ship that part of OpenArena as native-code in Debian
  because it needs to be compiled with a non-DFSG compiler)

* Start openarena from a terminal

* Go to the Mods menu

* Select "oa088upstream" and click Load

* Open the console (Shift+Escape), you should see messages like this
  near the end:

  > Loading vm file vm/ui.qvm...
  > File "vm/ui.qvm" found in "/home/smcv/.openarena/oa088upstream/vms.pk3"
  > ...which has vmMagic VM_MAGIC_VER2

  If you see something about "DLL files" near the end instead, then the
  package of bytecode has not worked and I'll have to provide better
  instructions.

* Close the console (Shift+Escape).

* Start a single-player game and try it.

If you have a working pre-Altivec, non-SPE PowerPC (probably a "G3" Mac)
or you know someone who does, that would also be useful to test on.
The current ioquake3 package probably fails on those machines,
but my PowerPC is (a) a G4 with Altivec and (b) broken, so I can't test that.

    S

Message #27 received at 701561@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Roland Stigge <stigge@antcom.de>, 701561@bugs.debian.org

Subject: Re: Bug#701561: ioquake3: FTBFS on powerpcspe

Date: Mon, 20 May 2013 00:35:50 +0100

[Message part 1 (text/plain, inline)]

On Mon, 20 May 2013 at 00:31:30 +0100, Simon McVittie wrote:
> [some instructions]
> 
> If you have a working pre-Altivec, non-SPE PowerPC (probably a "G3" Mac)
> or you know someone who does, that would also be useful to test on.

I forgot to attach a modified patch. Please try applying this patch
and setting USE_ALTIVEC=0 in debian/rules, instead of the version that
tests __NO_FPRS__ alongside Q3_VM.

Thanks,
    S

[0001-untested-Add-support-for-PowerPCs-without-Altivec.patch (text/x-diff, attachment)]

Message #32 received at 701561@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: 701561@bugs.debian.org, debian-powerpc@lists.debian.org

Subject: Please test ioquake3 on PowerPC, particularly without Altivec

Date: Tue, 4 Jun 2013 10:43:39 +0100

[Message part 1 (text/plain, inline)]

Hi debian-powerpc,
Could someone please test a patched ioquake3 on PowerPC, preferably one
without Altivec? Please reply to me or to the bug, I'm not subscribed to
debian-powerpc.

You will need 3D acceleration supported by Linux (which probably means
some sort of ATI/AMD or nVidia). Testing on any of these platforms is
welcome, as long as you know which one you're using:

* PowerPC with no Altivec (e.g. Mac G3)
* PowerPC with Altivec (e.g. Mac G4/G5)
* powerpcspe with no Altivec

Please test ioquake3 from Debian unstable, with the attached patch applied.
Testing the unpatched ioquake3 from unstable for comparison would also
be helpful.

Brief background, from #701561: ioquake3 currently always builds with Altivec.
This causes it to FTBFS on powerpcspe (where Altivec doesn't exist),
and only work on a subset of supported powerpc machines (since, AIUI,
Debian still supports G3 Macs and other non-Altivec PowerPCs).
I would like to fix this, but I don't have a working PowerPC, and
I'm concerned that the bytecode JIT might have a hidden dependency on Altivec.

You can test the engine using either Quake III Arena (non-distributable,
but somewhat easier) or OpenArena (DFSG-free). Instructions below.

Thanks,
    S

Testing with Quake III Arena
----------------------------

If you have a copy of Quake III Arena for any platform (the only bit you
actually need from the retail game is baseq3/pak0.pk3), please try with
Debian's contrib quake3 package. game-data-packager can package the
necessary non-distributable data to get this working.

Testing with OpenArena
----------------------

This is a bit more involved, because the Debian package doesn't normally
use the bytecode JIT, and that's the part I'm worried about:

* Install Debian's openarena package

* Download http://www.pseudorandom.co.uk/~smcv/oa088upstream/vms.pk3
  and put it in ~/.openarena/oa088upstream/vms.pk3
  (it contains bytecode executables for the UI, server-side game and
  client-side game - we ship that part of OpenArena as native-code in Debian
  because it needs to be compiled with a non-DFSG compiler)

* Start openarena from a terminal

* Go to the Mods menu

* Select "oa088upstream" and click Load

* Open the console (Shift+Escape), you should see messages like this
  near the end:

  > Loading vm file vm/ui.qvm...
  > File "vm/ui.qvm" found in "/home/smcv/.openarena/oa088upstream/vms.pk3"
  > ...which has vmMagic VM_MAGIC_VER2

  If you see something about "DLL files" near the end instead, then the
  package of bytecode has not worked and I'll have to provide better
  instructions.

* Close the console (Shift+Escape).

* Start a single-player game and try it.

[ioquake3-noaltivec.patch (text/x-diff, attachment)]

Message #37 received at 701561@bugs.debian.org (full text, mbox, reply):

From: "thinkbrown@gmail.com" <thinkbrown@gmail.com>

To: 701561@bugs.debian.org

Cc: debian-powerpc@lists.debian.org

Subject: Re: Please test ioquake3 on PowerPC, particularly without Altivec

Date: Tue, 4 Jun 2013 08:58:27 -0400

[Message part 1 (text/plain, inline)]

I have a few PowerMac machines, both with and without altivec, so I can see
about compiling with this patch. One thing I'd suggest is that altivec is
enabled based on the CPU itself, and not just PPC vs PPC64. I've had issues
like this before, specifically with VLC, and using altivec can result in a
pretty significant speed boost.

Is Rage128 still a supported 3D accelerator? I know it'll be slow as heck,
but it's the only card I have for my PowerMac G3s.

Logan Brown
On Jun 4, 2013 5:51 AM, "Simon McVittie" <smcv@debian.org> wrote:

> Hi debian-powerpc,
> Could someone please test a patched ioquake3 on PowerPC, preferably one
> without Altivec? Please reply to me or to the bug, I'm not subscribed to
> debian-powerpc.
>
> You will need 3D acceleration supported by Linux (which probably means
> some sort of ATI/AMD or nVidia). Testing on any of these platforms is
> welcome, as long as you know which one you're using:
>
> * PowerPC with no Altivec (e.g. Mac G3)
> * PowerPC with Altivec (e.g. Mac G4/G5)
> * powerpcspe with no Altivec
>
> Please test ioquake3 from Debian unstable, with the attached patch applied.
> Testing the unpatched ioquake3 from unstable for comparison would also
> be helpful.
>
> Brief background, from #701561: ioquake3 currently always builds with
> Altivec.
> This causes it to FTBFS on powerpcspe (where Altivec doesn't exist),
> and only work on a subset of supported powerpc machines (since, AIUI,
> Debian still supports G3 Macs and other non-Altivec PowerPCs).
> I would like to fix this, but I don't have a working PowerPC, and
> I'm concerned that the bytecode JIT might have a hidden dependency on
> Altivec.
>
> You can test the engine using either Quake III Arena (non-distributable,
> but somewhat easier) or OpenArena (DFSG-free). Instructions below.
>
> Thanks,
>     S
>
> Testing with Quake III Arena
> ----------------------------
>
> If you have a copy of Quake III Arena for any platform (the only bit you
> actually need from the retail game is baseq3/pak0.pk3), please try with
> Debian's contrib quake3 package. game-data-packager can package the
> necessary non-distributable data to get this working.
>
> Testing with OpenArena
> ----------------------
>
> This is a bit more involved, because the Debian package doesn't normally
> use the bytecode JIT, and that's the part I'm worried about:
>
> * Install Debian's openarena package
>
> * Download http://www.pseudorandom.co.uk/~smcv/oa088upstream/vms.pk3
>   and put it in ~/.openarena/oa088upstream/vms.pk3
>   (it contains bytecode executables for the UI, server-side game and
>   client-side game - we ship that part of OpenArena as native-code in
> Debian
>   because it needs to be compiled with a non-DFSG compiler)
>
> * Start openarena from a terminal
>
> * Go to the Mods menu
>
> * Select "oa088upstream" and click Load
>
> * Open the console (Shift+Escape), you should see messages like this
>   near the end:
>
>   > Loading vm file vm/ui.qvm...
>   > File "vm/ui.qvm" found in "/home/smcv/.openarena/oa088upstream/vms.pk3"
>   > ...which has vmMagic VM_MAGIC_VER2
>
>   If you see something about "DLL files" near the end instead, then the
>   package of bytecode has not worked and I'll have to provide better
>   instructions.
>
> * Close the console (Shift+Escape).
>
> * Start a single-player game and try it.
>

[Message part 2 (text/html, inline)]

Message #42 received at 701561@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: "thinkbrown@gmail.com" <thinkbrown@gmail.com>, 701561@bugs.debian.org

Cc: debian-powerpc@lists.debian.org

Subject: Re: Bug#701561: Please test ioquake3 on PowerPC, particularly without Altivec

Date: Tue, 04 Jun 2013 14:58:34 +0100

On 04/06/13 13:58, thinkbrown@gmail.com wrote:
> One thing I'd suggest is that
> altivec is enabled based on the CPU itself, and not just PPC vs PPC64.

Sorry, I'm not going to do significant development on this myself, but
if you or another powerpc porter want to put a patchset together,
upstream would probably take it.  There seems to be some support for
runtime detection already, but AIUI, compiling the whole thing with
-maltivec means that's useless, because gcc is within its rights to emit
Altivec instructions anyway?

Another possibility would be to have a separate "lowest common
denominator" Q3 binary for PowerPC-without-Altivec, and have it
transparently exec the Altivec binary (with the same command line) if it
determines that we do actually have Altivec. It would probably need to
behave like its own mini-architecture within the Quake 3 engine, with a
separate suffix or directory for loadable modules (perhaps *ppc.so for
Altivec and *oldppc.so for non-Altivec?)

What I'm more concerned about is whether the PowerPC JIT for the Quake 3
bytecode language (code/qcommon/vm_powerpc*) emits Altivec opcodes - I
have no idea how I'd determine that. That's why I'm specifically asking
for testing with the bytecode game logic.

> Is Rage128 still a supported 3D accelerator? I know it'll be slow as
> heck, but it's the only card I have for my PowerMac G3s.

Your guess is as good as mine :-)

If all G3s are likely to be this low-spec, perhaps ioquake3/powerpc
should just continue to require Altivec, and put a note in xmessage(1)
on older machines...

    S

Message #47 received at 701561@bugs.debian.org (full text, mbox, reply):

From: "thinkbrown@gmail.com" <thinkbrown@gmail.com>

To: Simon McVittie <smcv@debian.org>

Cc: 701561@bugs.debian.org, "debian-powerpc@lists.debian.org" <debian-powerpc@lists.debian.org>

Subject: Re: Bug#701561: Please test ioquake3 on PowerPC, particularly without Altivec

Date: Tue, 4 Jun 2013 10:37:19 -0400

On Tue, Jun 4, 2013 at 9:58 AM, Simon McVittie <smcv@debian.org> wrote:
> On 04/06/13 13:58, thinkbrown@gmail.com wrote:
>> One thing I'd suggest is that
>> altivec is enabled based on the CPU itself, and not just PPC vs PPC64.
>
> Sorry, I'm not going to do significant development on this myself, but
> if you or another powerpc porter want to put a patchset together,
> upstream would probably take it.  There seems to be some support for
> runtime detection already, but AIUI, compiling the whole thing with
> -maltivec means that's useless, because gcc is within its rights to emit
> Altivec instructions anyway?
>
> Another possibility would be to have a separate "lowest common
> denominator" Q3 binary for PowerPC-without-Altivec, and have it
> transparently exec the Altivec binary (with the same command line) if it
> determines that we do actually have Altivec. It would probably need to
> behave like its own mini-architecture within the Quake 3 engine, with a
> separate suffix or directory for loadable modules (perhaps *ppc.so for
> Altivec and *oldppc.so for non-Altivec?)
>
> What I'm more concerned about is whether the PowerPC JIT for the Quake 3
> bytecode language (code/qcommon/vm_powerpc*) emits Altivec opcodes - I
> have no idea how I'd determine that. That's why I'm specifically asking
> for testing with the bytecode game logic.

I did some tinkering with runtime detection when I was working on
getting PPC64 support under Quake II, so I'll see if I can make
something work. Maybe  *ppcaltivec.so, *ppc.so, and *ppc64.so

>
>> Is Rage128 still a supported 3D accelerator? I know it'll be slow as
>> heck, but it's the only card I have for my PowerMac G3s.
>
> Your guess is as good as mine :-)
>
> If all G3s are likely to be this low-spec, perhaps ioquake3/powerpc
> should just continue to require Altivec, and put a note in xmessage(1)
> on older machines...

Yeah, for the most part, non-altivec PPC/PPCSPE machines are probably
going to be incapable of running Quake III at a reasonable speed.
AFAIK, the highest end PCI card that there's a Macintosh ROM for is
the Radeon 7000.


I'll see if I can get a build machine up later today, since actually
compiling on a G3 would be exceptionally slow.


Logan

Message #52 received at 701561@bugs.debian.org (full text, mbox, reply):

From: Hiroyuki Yamamoto <yama1066@gmail.com>

To: 701561@bugs.debian.org, debian-powerpc@lists.debian.org

Subject: Re: Bug#701561: Please test ioquake3 on PowerPC, particularly without Altivec

Date: Wed, 05 Jun 2013 11:21:28 +0900

Hi,

I'm a porter of ppc64 port.

Unluckyly, ppc64 buildd nodes and my machines are shifting of place,
and they are offline now.
(If no trouble, plobably they will revive to online
on 2013-06-16.)

So, this build test cannot be done now,
but on ppc64 port, the packages have been tested
to be built packages with Altivec option as default,
unless package maintainers specify build options.

If buildlogs till now are helpful, please refer to them.
http://buildd.debian-ports.org/status/logs.php?pkg=ioquake3&arch=ppc64

Regards,
--
Hiroyuki Yamamoto

(2013/06/04 23:37), thinkbrown@gmail.com wrote:
> On Tue, Jun 4, 2013 at 9:58 AM, Simon McVittie <smcv@debian.org> wrote:
>> On 04/06/13 13:58, thinkbrown@gmail.com wrote:
>>> One thing I'd suggest is that
>>> altivec is enabled based on the CPU itself, and not just PPC vs PPC64.
>>
>> Sorry, I'm not going to do significant development on this myself, but
>> if you or another powerpc porter want to put a patchset together,
>> upstream would probably take it.  There seems to be some support for
>> runtime detection already, but AIUI, compiling the whole thing with
>> -maltivec means that's useless, because gcc is within its rights to emit
>> Altivec instructions anyway?
>>
>> Another possibility would be to have a separate "lowest common
>> denominator" Q3 binary for PowerPC-without-Altivec, and have it
>> transparently exec the Altivec binary (with the same command line) if it
>> determines that we do actually have Altivec. It would probably need to
>> behave like its own mini-architecture within the Quake 3 engine, with a
>> separate suffix or directory for loadable modules (perhaps *ppc.so for
>> Altivec and *oldppc.so for non-Altivec?)
>>
>> What I'm more concerned about is whether the PowerPC JIT for the Quake 3
>> bytecode language (code/qcommon/vm_powerpc*) emits Altivec opcodes - I
>> have no idea how I'd determine that. That's why I'm specifically asking
>> for testing with the bytecode game logic.
>
> I did some tinkering with runtime detection when I was working on
> getting PPC64 support under Quake II, so I'll see if I can make
> something work. Maybe  *ppcaltivec.so, *ppc.so, and *ppc64.so
>
>>
>>> Is Rage128 still a supported 3D accelerator? I know it'll be slow as
>>> heck, but it's the only card I have for my PowerMac G3s.
>>
>> Your guess is as good as mine :-)
>>
>> If all G3s are likely to be this low-spec, perhaps ioquake3/powerpc
>> should just continue to require Altivec, and put a note in xmessage(1)
>> on older machines...
>
> Yeah, for the most part, non-altivec PPC/PPCSPE machines are probably
> going to be incapable of running Quake III at a reasonable speed.
> AFAIK, the highest end PCI card that there's a Macintosh ROM for is
> the Radeon 7000.
>
>
> I'll see if I can get a build machine up later today, since actually
> compiling on a G3 would be exceptionally slow.
>
>
> Logan
>
>


-- 
Hiroyuki Yamamoto

Message #57 received at 701561@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: "thinkbrown@gmail.com" <thinkbrown@gmail.com>, 701561@bugs.debian.org

Cc: "debian-powerpc@lists.debian.org" <debian-powerpc@lists.debian.org>

Subject: Re: Bug#701561: Please test ioquake3 on PowerPC, particularly without Altivec

Date: Wed, 05 Jun 2013 13:34:01 +0100

On 04/06/13 15:37, thinkbrown@gmail.com wrote:
> I did some tinkering with runtime detection when I was working on
> getting PPC64 support under Quake II, so I'll see if I can make
> something work. Maybe  *ppcaltivec.so, *ppc.so, and *ppc64.so

The reason I suggested that *ppc.so should be the Altivec flavour (if
there's a separate non-Altivec flavour) is that these suffixes are used
by upstream; they're a plugin ABI of sorts. There's a rather awkward
correspondence between the build system (which, upstream, derives them
from uname(1)) and q_platform.h (which derives them from cpp's built-in
preprocessor definitions), which need to stay in sync.

Upstream always build *ppc.so with Altivec, so if we introduce a new
one, I'd be inclined to keep that suffix for the setup they support, and
introduce the Debian-specific one for the setup they don't. 64-bit
PowerPC is already *ppc64.so upstream.

Upstream also have a different per-architecture name for the executables
(e.g. ioquake3.ppc, ioquake3.x86, ioq3ded.ppc) - in Debian we rename
them to just "ioquake3" and "ioq3ded", so that wrapper shell scripts for
particular games don't need to know the right magic suffix.

In Debian we use the dpkg architecture instead of uname(1), then
post-process it to get the same answer (/usr/share/ioquake3/q3arch).

    S

Message #66 received at 701561@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: "thinkbrown@gmail.com" <thinkbrown@gmail.com>, 701561@bugs.debian.org

Cc: debian-powerpc@lists.debian.org, Roland Stigge <stigge@antcom.de>

Subject: Re: Bug#701561: Please test ioquake3 on PowerPC, particularly without Altivec

Date: Sat, 25 Jan 2014 13:50:17 +0000

On Tue, 04 Jun 2013 at 14:58:34 +0100, Simon McVittie wrote:
> What I'm more concerned about is whether the PowerPC JIT for the Quake 3
> bytecode language (code/qcommon/vm_powerpc*) emits Altivec opcodes - I
> have no idea how I'd determine that. That's why I'm specifically asking
> for testing with the bytecode game logic.

Any update on whether ioquake3 can work on non-Altivec PowerPCs,
either powerpc or powerpcspe, with the patch and testing procedure
from <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701561#32>?

I'm considering #701561 to be "won't fix" until/unless someone tells me
that it can actually work (and not just compile).

    S

Message #77 received at 701561-close@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: 701561-close@bugs.debian.org

Subject: Bug#701561: fixed in ioquake3 1.36+u20180108~dfsg-1

Date: Thu, 11 Jan 2018 09:36:08 +0000

Source: ioquake3
Source-Version: 1.36+u20180108~dfsg-1

We believe that the bug you reported is fixed in the latest version of
ioquake3, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 701561@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Simon McVittie <smcv@debian.org> (supplier of updated ioquake3 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Thu, 11 Jan 2018 08:56:14 +0000
Source: ioquake3
Binary: ioquake3 ioquake3-server
Architecture: source
Version: 1.36+u20180108~dfsg-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Games Team <pkg-games-devel@lists.alioth.debian.org>
Changed-By: Simon McVittie <smcv@debian.org>
Description:
 ioquake3   - Game engine for 3D first person shooter games
 ioquake3-server - Engine for 3D first person shooter games - server and common file
Closes: 701561
Changes:
 ioquake3 (1.36+u20180108~dfsg-1) unstable; urgency=medium
 .
   [ Pino Toscano ]
   * Recommend kdialog instead of kdebase-bin
 .
   [ Simon McVittie ]
   * Declare compliance with Debian Policy 4.1.3
   * Update Homepage field to use a https URL
   * New upstream snapshot (commit 6387c336)
     - Refresh patches
   * d/p/Disable-Altivec-instructions-on-PowerPC-unless-requested.patch:
     Add patch to compile without Altivec to support baseline powerpc
     CPUs. Thanks to GitHub user casey-ac for testing this change.
     This should also work on powerpcspe (Closes: #701561)
Checksums-Sha1:
 d04271b51af829e35667698ed35f18659daa09e3 2291 ioquake3_1.36+u20180108~dfsg-1.dsc
 0de22b27a462511ee7da3613dcc343a9c109c118 1906300 ioquake3_1.36+u20180108~dfsg.orig.tar.xz
 14dbca08fa8f6ebf488e2fc38423640e0ce43982 24060 ioquake3_1.36+u20180108~dfsg-1.debian.tar.xz
 006bcce826be1028bb89432a7b4da93fc84b2e14 11156 ioquake3_1.36+u20180108~dfsg-1_source.buildinfo
Checksums-Sha256:
 75a1f87bc2285c5d85fd4b5f69f859e111fdd70cc31442977cb5dbaba0c4d0cb 2291 ioquake3_1.36+u20180108~dfsg-1.dsc
 a2d5147f60d605baf4afea0fc7f1aee6be46a41f9dd87fe6353a55b26d4dfdbc 1906300 ioquake3_1.36+u20180108~dfsg.orig.tar.xz
 e2f8fc3610e470328e63537657476cd21c1d1901d00c057cb23880380379b8e5 24060 ioquake3_1.36+u20180108~dfsg-1.debian.tar.xz
 27fe52b982de551dfbb5f19ae6018a80fcabc8d5999506b342bac2d3a4409d3d 11156 ioquake3_1.36+u20180108~dfsg-1_source.buildinfo
Files:
 67397d16f30b81b4fe0f18400ef9943b 2291 games optional ioquake3_1.36+u20180108~dfsg-1.dsc
 982b2e79cd5c9c59bf361f698381bc01 1906300 games optional ioquake3_1.36+u20180108~dfsg.orig.tar.xz
 bff24170e55676dd37ba5629c89ba70e 24060 games optional ioquake3_1.36+u20180108~dfsg-1.debian.tar.xz
 7a153f8d326fb16b20faff554ebc44d5 11156 games optional ioquake3_1.36+u20180108~dfsg-1_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEENuxaZEik9e95vv6Y4FrhR4+BTE8FAlpXLJYACgkQ4FrhR4+B
TE9SEA/9GRLyd8g3fccxAtQ4R4h8NV0vEbpu3mmPSR1TsotBWIJSUqgtTSp7Wctd
LbfhxBT/rPYZrvvZKe1fhBQpRGkesMWxMdvnbqeYM1LxIT06OkxbsE2FJusJKMif
e98z6egLsh/mFJ288i1qAtEpumvghmQ7pLmm/uQtDZ2/0JPn/e8koHtYOngH57PV
8CbSnT7gBjvv6xIIO29hRPens+vD3rEunSft19oDFwiBk8DOp3Bv5lX2Tpn4qA4x
ZqQHKWdVohgyxCSKp5koCet/JBFCTIGMfPMtKegkvLAv0m/08ayKnT/7LhWHW5Db
LXod14w/0sdc3KROa/7biyiJzEAEy6REmSGKNl3GC76KSBcfpYkihkxUlBHiZCo5
Beidr8XaacJK7yiY4SaUZP8dlrqA6WhlpYXwz5q8wa50voxj/e3rLspyWeZ6rm/6
eDeGiQx6A937N2GYl/2iJ1uJQqCQNdEQ+NBN0kjeOkSAgMKu63EO8BnjWZFu70wb
8KPwRa0MiExldt2YM+gD7rihMMfR4PONBid1652fjL9xExZS6Ghc+6vl9BmZLFT8
ebYh9PBrp8qCZszymuZGFprqrGWY4NB+YiftNCsSz1uFKhXb9i9AWCmh3fmOIl/v
tUSOX6Kkd7s7Ep+oPRshhkpdjgKWzVwzOsrk7O5b6+YJXeBbCa4=
=eFGM
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.