Bug#942113: 3depict: FTBFS on PPC64EL - POWERPC macro not always defined

Olly Betts olly at survex.com
Thu Oct 17 04:12:35 BST 2019


On Wed, Oct 16, 2019 at 11:30:47AM +0200, Thierry Fauck at linux.ibm.com wrote:
> I've personally always used __powerpc__ .
> Here is my reference, very useful for all arch related defines :
> https://wiki.debian.org/ArchitectureSpecificsMemo

That page documents what's defined by GCC on Debian, but this check is
for the metroworks compiler, so to fix this properly the question is
really what that compiler defines on powerpc platforms.

But looking more closely, I think this probably should be a defined-ness
check:

#if defined __MWERKS__ && defined __POWERPC__

But also, I see this code is in a header from a different package
(libqhull-dev) so it seems this is really a bug in that.

I would reassign, but I'm wondering if I'm missing something here -
qhull was last uploaded in 2017 and ten other packages build-depend on
libqhull-dev, so why aren't they all FTBFS on ppc64el too?

$ reverse-depends -b libqhull-dev
Reverse-Build-Depends
=====================
* 3depict
* gdal
* getfem++
* gnudatalanguage
* meshlab
* octave
* pcl
* plplot
* pymca
* ros-geometric-shapes
* saga

And why does this only cause an error on one architecture?  I downloaded
and compared the headers in the amd64 and ppc64el libqhull-dev packages
and they're identical.  If neither __MWERKS__ nor __POWERPC__ are
defined on ppc64el then the same situation should exist on amd64.  If
__POWERPC__ *is* defined on ppc64el that could be a difference - I can't
connect to the ppc64el porterbox to check though.  But testing this on
amd64 I get no error anyway:

#if __MWERKS__ && __amd64__

Cheers,
    Olly



More information about the debian-science-maintainers mailing list