On Aug 15, 2019, at 14:05, Chris Jones wrote:
> On 15 Aug 2019, at 6:44 pm, Ryan Schmidt wrote:
>
>>> On Aug 15, 2019, at 12:36, Bill Stackhouse wrote:
>>>
>>> :info:build /opt/local/bin/ranlib: object: .libs/libapr-1.a(apr_encode.o)
>>> malformed object (unknown load command 1)
>>
>> This means your cctools port is too old to understand what's coming out of
>> the compiler. Try reinstalling the cctools port with the +xcode variant.
>
> Note that the xcode variant is no longer the default. i would recommend
> instead just using the current defaults of cctools.
If that works, sure.
But the xcode variant is the only variant that effectively changes the version
of the software provided. Without the xcode variant, the port builds a cctools
version comparable to that shipped with Xcode 10.0. If the code produced by the
compilers in the current more-recent version of Xcode is no longer compatible
with the cctools software from Xcode 10.0, then using default variants will not
work, and the xcode variant will have to be used, until such a time as Apple
releases a newer version of the cctools source code and the cctools port is
updated to that version.
Or you could be right. It could be that it's the llvm version that matters, and
building cctools with an older llvm variant will not work with the object files
produced by newer Xcode's compilers. If that's the case, then just using a
newer llvm variant is the solution.