[PROJ] Problems in CI: MacOS build

[Greg Troxel]

Javier Jimenez Shaw via PROJ <proj at lists.osgeo.org> writes:

> https://github.com/OSGeo/PROJ/actions/runs/31825301827/job/94847898881
>
>     Linking C executable cmTC_51f2b
>     /Users/runner/micromamba/envs/proj/bin/cmake -E cmake_link_script
> CMakeFiles/cmTC_51f2b.dir/link.txt --verbose=1
>     ld: -lto_library library filename must be 'libLTO.dylib'
>     clang: error: linker command failed with exit code 1 (use -v to see
> invocation)

Standard rant about cmake and modern build systems: Actual build lines
are often suppressed in favor of eye candy.  Nobody reads build output
until something goes wrong, so we should turn on enough verbosity to
print the commands being executed, always.  I see a line to invoke some
ld script with cmake and then an ld error message but not the ld
invocation.   I think this can be done in CMakeFile.txt

This error is perhaps reproducible with just a cmakefile that runs this
test, out of proj context, and is likely some blend of a cmake bug and
an apple bug.

Perhaps LTO can be disabled.

> https://github.com/jjimenezshaw/PROJ/actions/runs/31823956660/job/94843554428
>
> In file included from
> /Users/runner/work/PROJ/PROJ/build_from_dist/proj-9.9.0/shared_build/_deps/googletest-src/googletest/include/gtest/gtest-matchers.h:49:
> /Users/runner/work/PROJ/PROJ/build_from_dist/proj-9.9.0/shared_build/_deps/googletest-src/googletest/include/gtest/gtest-printers.h:520:35:
> error: implicit conversion from 'char16_t' to 'char32_t' may change the
> meaning of the represented code unit [-Werror,-Wcharacter-conversion]
>   520 |   PrintTo(ImplicitCast_<char32_t>(c), os);
>       |           ~~~~~~~~~~~~~           ^
> 1 error generated.

I am guessing that char16_t is like char in C, where it is up to the
implementation to decide if it is signed or unsigned as a variable, and
that char16_t holds unicode, but only 0-65535, and char32_t can hold
0-{2^32-1].  If my guess is right, then values 32768-65535 have
implementation-chosen sign extension behavior and if the unicode code
points are unsigned (which they probably are), one of those choices is
wrong.

Perhaps somebody who understands the complexities of unicode better than
I do (I was raised ASCII, and excited to have lower case!) can explain
if characters are supposed to be signed or not and related issues.

> [ 30%] Linking CXX shared library ../lib/libproj.dylib
> Undefined symbols for architecture arm64:
>   "___divdc3", referenced from:
>       complex_horner_iterative_inverse_4d(PJ_COORD&, PJconsts*) in
> unity_22_cxx.cxx.o
> ld: symbol(s) not found for architecture arm64
> clang++: error: linker command failed with exit code 1 (use -v to see
> invocation)>

I think the plan is for compilers to be able to use functions for
complicated math, with an implementation strategy that sometimes they
are replaced by machine instructions and sometimes by assembler
routines.

My guess is that this is a situation where compiling the file used such
a function but for some reason it isn't in the standard library used at
link time.  That could be a toolchain bug, and it could be a build
system issue if multiple toolchains are in scope somehow and -L options
lead to using the wrong standard library.

Apparently this is a common woe:
  https://github.com/llvm/llvm-project/issues/54596


I have kicked off a build of proj master on NetBSD 10 aarch64, using gcc
10.  I'll follow up with how that went; it's going to take a while
because the machine is slow.