[ace-users] ACE 6.5.11 on macOS 10.15.6 (Catalina) using clang++

[Brad Howes]

HI,

I recently checked out an old project of mine (https://github.com/bradhowes/sidecar <https://github.com/bradhowes/sidecar>) that uses ACE for message marshaling and stream processing. Miraculously, it still compiles on CentOS 8 without a problem, and up until a few month ago it was also building fine on macOS 10.15 using an install of ACE from the `brew` package manager, but upgrading to the latest version 6.5.11 caused a compile issue:

Undefined symbols for architecture x86_64:
  "ACE_InputCDR::read_8(unsigned long long*)", referenced from:
      SideCar::Parameter::TValue<SideCar::Parameter::Defs::Double>::checkedLoad(ACE_InputCDR&) in ParameterTest.cc.o
      SideCar::Parameter::TValue<SideCar::Parameter::Defs::Double>::load(ACE_InputCDR&) in ParameterTest.cc.o
      SideCar::Parameter::TValue<SideCar::Parameter::Defs::RangedDouble<DoubleRange> >::checkedLoad(ACE_InputCDR&) in ParameterTest.cc.o
      SideCar::Parameter::TValue<SideCar::Parameter::Defs::RangedDouble<DoubleRange> >::load(ACE_InputCDR&) in ParameterTest.cc.o
  "ACE_OutputCDR::write_8(unsigned long long const*)", referenced from:
      SideCar::Parameter::TValue<SideCar::Parameter::Defs::Double>::write(ACE_OutputCDR&) const in ParameterTest.cc.o
      SideCar::Parameter::TValue<SideCar::Parameter::Defs::RangedDouble<DoubleRange> >::write(ACE_OutputCDR&) const in ParameterTest.cc.o

Looking at the symbols in the `libACE.dylib` file, I saw this signature:

000000000002eac0 T ACE_InputCDR::read_8(unsigned long*)

I removed the `brew` package and downloaded the 6.5.11 tarball from https://download.dre.vanderbilt.edu <https://download.dre.vanderbilt.edu/> and customized the configure file
`ace/config-macosx.h` with:

    #if defined(__clang__) && defined(__x86_64__)
    #define ACE_INT64_TYPE long long int
    #define ACE_UINT64_TYPE unsigned long long int
    #endif

This seems to have fixed the issue with compiling and my unit/integration tests all run fine so I think it is working, but I am unsure if this is the right approach. Perhaps someone knows of a better way to fix what I observed? I am more than happy to submit a pull request if that is desired, amended with whatever feedback anyone may have.

Regards,

Brad


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.isis.vanderbilt.edu/pipermail/ace-users/attachments/20200831/bf26b67d/attachment.html>