When `CMAKE_INSTALL_LIBDIR` and `CMAKE_INSTALL_INCLUDEDIR` are set to relative paths, the `msgpack-c.pc` file generated by CMake improperly configures `libdir` and `includedir`. This leads to incorrect paths that prevent the compiler from locating necessary header and library files.
Build and install `msgpack-c`.
```console
% git switch -c c_master
% cmake -S . -B ../msgpack-c.build -DCMAKE_INSTALL_PREFIX=/tmp/local -DCMAKE_INSTALL_LIBDIR=lib-relative -DCMAKE_INSTALL_INCLUDEDIR=include-relative
% cmake --build ../msgpack-c.build
% cmake --install ../msgpack-c.build/
```
Compile `example/simple_c.c` using installed msgpack-c.
The following error happens because the linker cannot find paths provided by pkg-config.
```console
% export PKG_CONFIG_PATH=/usr/local/lib-relative/pkgconfig:$PKG_CONFIG_PATH
% gcc -o simple_c example/simple_c.c $(pkg-config --cflags --libs msgpack-c)
/usr/bin/ld: cannot find -lmsgpack-c: No such file or directory
collect2: error: ld returned 1 exit status
```
Successly compile `example/simple_c.c` using install msgpack-c.
We can execute `simple_c.c` like the following.
```console
% gcc -o simple_c example/simple_c.c $(pkg-config --cflags --libs msgpack-c)
% ./simple_c
93 01 c3 a7 65 78 61 6d 70 6c 65
[1, true, "example"]
```
The generated `msgpack-c.pc` file does not handle relative paths correctly. Here is the result of the incorrect configuration in How to reproduce section.
In the following `msgpack-c.pc` file, `libdir` and `includedir` are relative to the current directory, leading to incorrect paths.
```console
cat ../msgpack-c.build/msgpack-c.pc
prefix=/tmp/local
exec_prefix=/tmp/local
libdir=lib-relative
includedir=include-relative
Name: MessagePack
Description: Binary-based efficient object serialization library
Version: 6.0.1
Libs: -L${libdir} -lmsgpack-c
Cflags: -I${includedir}
```
Modify the `msgpack-c.pc.in` file to ensure that `libdir` and `includedir` use absolute paths by prefixing them with ${prefix}/. This change addresses the issue by providing correct paths to the compiler and linker.
Building msgpack gives currently gives the following warning:
"CMake Deprecation Warning at CMakeLists.txt:1 (CMAKE_MINIMUM_REQUIRED):
Compatibility with CMake < 3.5 will be removed from a future version of
CMake.
Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions."
Reuse same solution as fc18087cdf as the
policy CMP0060 introduced in cmake 3.3 causes problems with when linking
for 32-bit otherwise.
Removing CMAKE_INSTALL_PREFIX allows for `cmake --install <build-dir>
--prefix=<installation-prefix>` to install headers at
`<installation-prefix>/include` at install time.
When CMAKE_INSTALL_PREFIX is present in `INSTALL()`, it is hard-coded
during configuration (e.g., `cmake -S .`), which disallows it from being
set at install time.
Ubuntu 18.04 is deprecated on GitHub Actions. Additionally:
- Install 'clang' to get the latest clang toolchain.
- Use -gdwarf-4 so Valgrind understands the debug information.
- Install latest version of gtest (v1.13.0).
- Show compile and link commands when building.
- `cat` Valgrind output on error.
CMake assumes the default project uses both C and C++, and therefore
will fail if both a C and a C++ compiler isn't found. This essentially
blocks pure C projects from using msgpack-c if they also don't have a
C++ compiler.
Just specifying that the project is "C" isn't possible though, as the
test themselves use C++. The workaround here is that we specify the
project needs both a C and C++ compiler if tests are used, but only a C
compiler if the tests aren't used.
If (u)intptr_t exist, the only guarantee provided by the C standard is
that you can cast a pointer to one and back. No claims are made about
what that injective pointer-to-integer mapping is, nor the surjective
reverse integer-to-pointer mapping; for example, nowhere is it specified
that, given a char *p, p + 1 == (char *)((uintptr_t)p + 1), although no
sensible implementation would make that not the case (provided p is a
valid strictly in bounds pointer).
With real pointers, taking them out of bounds (other than the one
exception that is a one-past-the-end pointer) of their corresponding
allocation is UB. Whilst the semantics of arithmetic on uintptr_t is not
specified when cast back to a pointer, compilers already assume that
uintptr_t arithmetic does not go out of bounds (or, put another way,
that the result always ends up pointing to the same allocation) and
their alias analysis-based optimisations already assume this. CHERI, and
Arm's Morello, implement C language pointers with hardware capabilities,
which are unforgeable pointers with bounds and permissions. In order to
only double rather than quadruple the size of pointers, CHERI exploits
C's requirement that pointers not be taken out of bounds, and compresses
these bounds using a floating-point-like representation. The important
implication of this for most software is that if a capability, i.e. C
pointer in CHERI C, is taken too far out of bounds (where "too far" is
proportional to the size of the allocation) it can no longer be
represented and thus is invalidated, meaning it will trap on a later
dereference. This also extends to (u)intptr_t, which are also
implemented as capabilities, since if it were just a plain integer then
casting a pointer to (u)intptr_t would lose the metadata and break the
ability to cast back to a pointer.
Whilst the composition of dividing a pointer and then multiplying it
again has a somewhat sensible interpretation of rounding it down (even
though technically no such guarantees are made by the spec), the
individual operations do not, and the division is highly likely to take
the pointer far out of bounds of its allocation and, on CHERI, result in
it being unrepresentable and thus invalidated. Instead, we can perform a
more standard bitwise AND with a mask to clear the low bits, exploiting
the fact that alignments are powers of two; note that technically the
rounding up variant of this does take the pointer out of bounds slightly
and, whilst there are other ways to write such code that avoid doing so,
they are more cumbersome, and this code does not need to worry about
that.
The only integral types guaranteed by the C standard, if they exist, to
support having a pointer cast to them and back are (u)intptr_t. On most
architectures, size_t and uintptr_t are typedefs for the same underlying
type, so this code ends up working. However, on CHERI, and thus Arm's
experimental Morello prototype, C language pointers are implemented with
hardware capabilities, which are unforgeable pointers with bounds and
permissions. This means that, whilst size_t remains a plain 32/64-bit
integer size, (u)intotr_t is represented with a capability. Casting to
size_t and back to a pointer causes the capability metadata to be lost
and the resulting capability to be invalid, meaning it will trap when
dereferenced. Instead, use uintptr_t, and provide fallback definitions
for old versions of MSVC like for the other C99 integer types.
