[118041] trunk/dports/databases/mysql56

[Ryan Schmidt]

On Mar 20, 2014, at 19:13, Marcus Calhoun-Lopez wrote:

> I submitted the patch that was committed in r118041.
> I will try to explain my tortured logic.
> 
> mysql was already silently using g++ as the C++ compiler for 32-bit builds.
> Apparently, clang caused a problem at some point (See #42943 for more details).
> 
> Some possible solutions were:
> 1) Blacklist clang for 32-bit builds, in which case MacPorts would fallback to llvm-gcc42.
>        Since llvm-gcc42 is not working on Mavericks (#42849), this did not seem like an optimal choice.

That must be a new problem. I have llvm-gcc42 installed on Mavericks.


> 2) For 32-bit builds, blacklist versions of clang in use at the time the problem was first reported.
>        Since there is no guarantee that subsequent version of clang (or mysql) fixed the problem,
>        this also seemed less than ideal.

#42943 says the problem was "Clang on 32 bit causes non-debug server to crash”. So we should reproduce that problem, then figure out if newer versions of clang fix it. If so, blacklist older clang. If not, blacklist all clang. And also poke the MySQL developers about what they’re planning on doing about this issue.


> 3) Set "configure.compiler gcc”

But “gcc” *is* clang as of Xcode 5. If all versions of clang cause the crash, then this is not helping anything. And if this version of clang does not cause this crash, then blacklist older clang.


> 4) Let mysql continue to use whichever g++ it could find.
>        This is more or less the same as setting "configure.compiler gcc"
>        At least setting configure.compiler makes the ambiguity obvious.
>        Is that a virtue?
> 
> Solution 4 seemed to be the lesser of the evils.
> I hope I did not miss an obvious solution.