> That is going to be badly broken somewhere along the line for at least some
> CPU targets: don't try to ship that!
oops. already done. oh well.
>This is all fixed properly in git master (because Blue Swirl committed a lot
> of patches that let us finally drop the need for that global register
> variable), so either:
> (1) compile with a real gcc (not llvm-gcc or clang)
> (2) use git master
> (3) wait for 1.3.
Thanks for the explanation.
option (1) is a pain for 10.7/8 because it means dependence on fink's gcc.
option (2) is not straight forward, because a fink package needs a fixed base of source code. Although it means some extra works, this seems the way to go, though. A brief check of the git commits revealed that the number of commits is rather large and it is probably best to base the fink package on a distinct commit. I will try that in the next days.
> That is going to be badly broken somewhere along the line for at least some
> CPU targets: don't try to ship that!
oops. already done. oh well.
>This is all fixed properly in git master (because Blue Swirl committed a lot
> of patches that let us finally drop the need for that global register
> variable), so either:
> (1) compile with a real gcc (not llvm-gcc or clang)
> (2) use git master
> (3) wait for 1.3.
Thanks for the explanation.
option (1) is a pain for 10.7/8 because it means dependence on fink's gcc.
option (2) is not straight forward, because a fink package needs a fixed base of source code. Although it means some extra works, this seems the way to go, though. A brief check of the git commits revealed that the number of commits is rather large and it is probably best to base the fink package on a distinct commit. I will try that in the next days.
Michael