[MacPorts] #67773: mosh at 1.4.0: numerous C++ compilation errors on 10.5.8 PPC (when building with nonstandard gcc12 compiler)

[MacPorts]

#67773: mosh at 1.4.0: numerous C++ compilation errors on 10.5.8 PPC (when building
with nonstandard gcc12 compiler)
-----------------------+--------------------
  Reporter:  acjones8  |      Owner:  (none)
      Type:  defect    |     Status:  new
  Priority:  Normal    |  Milestone:
 Component:  ports     |    Version:
Resolution:            |   Keywords:  ppc
      Port:  mosh      |
-----------------------+--------------------

Comment (by acjones8):

 Alright, I think I figured it out! Your gut instinct about different
 headers or header definitions seems to have been correct.

 You mentioned that you were able to build mosh without any issues if you
 disabled AltiVec. We've been passing in `-faltivec` to enable it, so I
 thought... maybe `-fno-altivec` will disable it. Trying that solution, it
 actually works - mosh builds and functions perfectly as far as I can tell.
 I'm very relieved to have it back, but I wasn't really happy with not
 having AltiVec, since my understanding is it can make quite a decent
 performance improvement on these older processors.

 So I dug a little deeper. I didn't realize what "vec_or" meant earlier,
 but I discovered that it's an intrinsic that does a logical or between two
 vectors. I figured GCC wouldn't be suggesting it as an alternative to
 "vector" if it wasn't defined, so it seemed like `altivec.h` was getting
 imported properly. So I dug around and found it at
 `/opt/local/lib/gcc12/gcc/ppc-apple-darwin9/12.3.0/include/altivec.h`.
 Upon examining it, I found this interesting chunk of code:
 {{{
 /* If __APPLE_ALTIVEC__ is defined, the compiler supports 'vector',
    'pixel' and 'bool' as context-sensitive AltiVec keywords (in
    non-AltiVec contexts, they revert to their original meanings,
    if any), so we do not need to define them as macros.  Also,
    avoid defining them as macros for C++ with strict ANSI, as
    this is not compatible.  */

 #if !defined(__APPLE_ALTIVEC__) \
     && (!defined(__STRICT_ANSI__) || !defined(__cplusplus))
 #define vector __vector
 #define pixel __pixel
 #define bool __bool
 #endif
 }}}

 I'm in a little over my head here, but it seems like GCC redefines vector
 to `__vector` on non-apple platforms (among other reasons). I tried
 passing in `__APPLE_ALTIVEC__` like you did earlier with `__ALTIVEC__`
 using configure-append, but that didn't help any. Then I thought, maybe
 I'll just try manually redefining vector to `__vector` in the altivec code
 block in mosh. And that's the trick - GCC has no further complaints after
 that, the code compiles without any errors. I haven't extensively stress
 tested it, but after logging into my server and editing for a couple of
 minutes, everything seems to work fine, it behaves exactly as it did above
 without altivec. I was a little suspicious, but by disassembling the mosh
 binary using `otool -tvV`, I can see a few `vsplt` instructions in it,
 which the altivec manual I found says are vector splat commands. So it
 doesn't seem like this "fixes" the problem by disabling altivec in a
 roundabout way, it *does* seem to actually be using altivec now.

 So - with all that said, would it be okay if I offered a patch that fixes
 this problem? It would only need to add a single line of code, `#define
 vector __vector` at the top of the AltiVec block in ocb_internal.cc . I
 figure the potential impact should be minimal, since only G4 and G5
 PowerPC users will ever use the AltiVec block anyway. It's very strange
 that mosh seems to have this issue, since as mentioned, openssh and other
 programs seem to compile with AltiVec support just fine... which I
 verified by using otool to disassemble `/opt/local/bin/ssh` and seeing
 lots of `vsplt` instructions, just like how my own test program has
 `vaddfp` in it.

-- 
Ticket URL: <https://trac.macports.org/ticket/67773#comment:8>
MacPorts <https://www.macports.org/>
Ports system for macOS