Changes between Initial Version and Version 1 of Ticket #45832, comment 2


Ignore:
Timestamp:
Nov 15, 2014, 5:06:27 PM (10 years ago)
Author:
udbraumann
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #45832, comment 2

    initial v1  
    1 PPC support of clang is less than weak. Either you can build it (e.g. versions 3.1 and 3.3) and it and clang compiles more or less garbage, or you cannot build clang itself (like 3.4; I think the experimental 3.5 or 3.6 are not worthwhile to try), see a small portion of this sad story here: https://trac.macports.org/ticket/43484 where two days ago the maintainer announced the compiling issues I was reporting months ago concerning cctools are now considered as "wontfix". I actually have forgotten how clang versions 2.9, 3.0 and 3.3 were behaving, but I do not think these were much different from those mentioned above.
     1PPC support of {{{clang}}} is less than weak. Either you can build it (e.g. versions 3.1 and 3.3) and it and clang compiles more or less garbage, or you cannot build clang itself (like 3.4; I think the experimental 3.5 or 3.6 are not worthwhile to try), see a small portion of this sad story here: https://trac.macports.org/ticket/43484 where two days ago the maintainer announced the compiling issues I was reporting months ago concerning {{{cctools}}} are now considered as "wontfix". I actually have forgotten how clang versions 2.9, 3.0 and 3.3 were behaving, but I do not think these were much different from those mentioned above.
    22
    33So for PPC and clang we are lost at present.
    44
    5 Practically spoken, any macports utility which should have a chance to be built on PPC cannot rely on clang. Instead, good old gcc-4.2 or macports-gcc-4.8 should be accepted (have not tried macports-gcc-4.9 so far).
     5Practically spoken, any macports utility which should have a chance to be built on PPC cannot rely on clang. Instead, good old {{{gcc-4.2}}} or {{{macports-gcc-4.8}}} should be accepted (have not tried {{{macports-gcc-4.9}}} so far).
    66
    7 For mozjs17 I have tried both of them but always get this "architecture was not detected as supported" error (also see my build log):
     7For {{{mozjs17}}} I have tried both of them but always get this "architecture was not detected as supported" error (also see my build log):
    88
    99{{{
    … …  
    1313}}}
    1414
    15 Looking into utils.h one can see that the architecture check obviously has failed, i.e. __powerpc__ has not been defined. So first guess is that this symbols needs to be defined before in order to let gcc-4.2 do the compilation of mozjs17. Hope this can be achieved via an official portfile modification, since I am sure it is not difficult to work around this issue.
     15Looking into utils.h one can see that the architecture check obviously has failed, i.e. {{{__powerpc__}}} has not been defined. So first guess is that this symbols needs to be defined before in order to let {{{gcc-4.2}}} do the compilation of {{{mozjs17}}}. Hope this can be achieved via an official portfile modification, since I am sure it is not difficult to work around this issue.