Don't link with non-existant utf8cpp library by marillat · Pull Request #345 · Matroska-Org/libebml

marillat · 2026-07-20T06:22:11Z

Fix issue #344

mbunkus · 2026-07-20T08:01:06Z

Thanks. I'll remove it & prepare a new release later today.

I've also a question, why utf8cpp 3.2.0 is mandatory when the latest upstream version is 4.1.1

You've removed this comment since, and I guess it's because we don't require that version — we require a version that's compatible with it (I think; I'm really not a CMake guy). My guess is that @robUx4 has chosen that version as that was the one we hand bundled up until @robUx4 replaced it by CMake using the system version. Steve?

marillat · 2026-07-20T08:25:21Z

You've removed this comment since, and I guess it's because we don't require that version — we require a version that's compatible with it (I think; I'm really not a CMake guy). My guess is that @robUx4 has chosen that version as that was the one we hand bundled up until @robUx4 replaced it by CMake using the system version. Steve?

I removed my question because I have seen a configure error saying utfcpp 3.2.0 is required but the error was related to the link with utf8cpp

robUx4 · 2026-07-20T11:38:01Z

As you can see, this patch is breaking the build. It is an integral part of 97f5a03.

If the library is missing we are missing proper UTF-8 support. Before that patch the code was hardcoded, now we download it, in case it's found in the system we don't have to download it. IIRC the 3.2.0 version matches the version we had before. Maybe newer versions can be built as well.

What is missing in #344 is that the CMake configuration should fail if your system don't have it as a library and it failed to be downloaded for some reason.

mbunkus · 2026-07-20T11:46:11Z

I think there's a misconception/miscommunication here:

Yes, we require the utf8cpp library. However, the utf8cpp library is a header-only library that doesn't produce a static (libutf8cpp.a) nor dynamic (libutf8cpp….so) link library to link against (there's no -lutf8cpp passed to the compiler).

robUx4 · 2026-07-20T11:50:19Z

Yes, we require the utf8cpp library. However, the utf8cpp library is a header-only library that doesn't produce a static (libutf8cpp.a) nor dynamic (libutf8cpp….so) link library to link against (there's no -lutf8cpp passed to the compiler).

Indeed, I missed that. However it fails to build without that line.

Maybe replacing it with this would work:

target_include_directories(ebml PRIVATE $<BUILD_INTERFACE:utf8cpp>)

robUx4 · 2026-07-20T11:52:04Z

I still wonder why it worked in all the CI so far but not in #344. Because we should have a way to find this issue in the CI.

mbunkus · 2026-07-20T11:52:33Z

The problem the tests fail over is finding the include files, though. On Ubuntu 26.04 the package in question is libutfcpp-dev which includes, among others:

/usr/include/utf8.h
/usr/include/utf8cpp/utf8/checked.h

We try to include <utf8/checked.h>, and my guess is that /usr/include/utf8cpp is not passed as an include path to the compiler via the existing cmake files. I don't currently know if this structure is the same on older versions of the library (it's 4.0.x on Ubuntu 26.04) & on other OSes. Will have to investigate what the common layout is.

robUx4 · 2026-07-20T11:55:49Z

We do have a CI job that uses the Debian package.

robUx4 · 2026-07-20T11:59:46Z

A job using the downloaded version:

CMake Warning at CMakeLists.txt:51 (find_package):
  By not providing "Findutf8cpp.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "utf8cpp", but
  CMake did not find one.

  Could not find a package configuration file provided by "utf8cpp"
  (requested version 3.2.0) with any of the following names:

    utf8cppConfig.cmake
    utf8cpp-config.cmake

  Add the installation prefix of "utf8cpp" to CMAKE_PREFIX_PATH or set
  "utf8cpp_DIR" to a directory containing one of the above files.  If
  "utf8cpp" provides a separate development package or SDK, be sure it has
  been installed.

...

-- libebml packages used:

A job using the Debian package:

-- libebml packages used:
 * utf8cpp (required version >= 3.2.0)

mbunkus · 2026-07-20T12:12:44Z

Yeah, on Ubuntu 26.04:

CMake Warning at CMakeLists.txt:51 (find_package):
  Could not find a configuration file for package "utf8cpp" that is
  compatible with requested version "3.2.0".

  The following configuration files were considered but not accepted:

    /usr/share/cmake/utf8cpp/utf8cppConfig.cmake, version: 4.0.9
      The version found is not compatible with the version requested.

marillat · 2026-07-20T12:13:30Z

A job using the Debian package:
-- libebml packages used:
 * utf8cpp (required version >= 3.2.0)

utf8cpp in Debian in patched to search cmake files in /usr/share/cmake/

https://salsa.debian.org/debian/utfcpp/-/blob/master/debian/patches/0003-CMakeLists.txt-Prefer-usr-share-cmake-for-cmake-file.patch?ref_type=heads

mbunkus · 2026-07-20T12:55:28Z

Isn't it possible that the issue is more about the utf8cpp version than the OS? ≥ 4 fails, < 4 works? (guesswork, haven't had time to investigate further yet)

marillat · 2026-07-20T13:00:38Z

Isn't it possible that the issue is more about the utf8cpp version than the OS? ≥ 4 fails, < 4 works? (guesswork, haven't had time to investigate further yet)

I'm able to build 1.4.6 with utf8cpp 4.1.1 in Debian unstable and for these arches amd64, arm64, armhf, i386, powerpc, riscv64

robUx4 · 2026-07-20T13:21:05Z

Can you try your failing configuration with this line instead ?

target_include_directories(ebml PRIVATE $<BUILD_INTERFACE:utf8cpp>)

mbunkus · 2026-07-20T14:53:07Z

On Ubuntu 26.04 I can remove the version constraint & then a) cmake finds & uses the library and b) building with make works fine. No git cloning is happening. No compiler or linker errors.

Meaning the only change I need on Ubuntu 26.04 is changing

find_package(utf8cpp 3.2.0)

to

find_package(utf8cpp)

I leave target_link_libraries(ebml PRIVATE $<BUILD_INTERFACE:utf8cpp>) as is.

I don't seem to be able to specify something as the version requirement that says something like "at least 3.2.0, but any 4.x.y is OK, too". I've tried 3.2.0...<5 but then cmake claims that the available 4.0.9 is not compatible with my requirement.

utf8cpp in Debian in patched to search cmake files in /usr/share/cmake/

I don't know what that is meant to explain. If a distribution packaged version of a library installs a cmake file, then it's up to the distribution package's manager (the person writing the debian/ stuff, for example) to ensure the file is in the right place for the also distribution packaged cmake to find. It's not up to us as application developers to have to care about making cmake find cmake files of distribution packaged libraries.

In my view there are possibly a number of things that are happening here at various points:

some of our build checks don't have the distribution's utf8cpp package installed, therefore cmake cannot find it, tries to clone the git repo, and that fails for some reason
due to the version requirement of 3.2.0 cmake doesn't consider an installed 4.x.y to be a suitable candidate, doesn't use it, and hence building fails if git cloning also fails
marillat's problem: for some reason an -lutf8cpp happens during his build process that should definitely not happen; I do not understand yet why

The first point is something we need to investigate independently of a new release; it's an infrastructure question.

The second point is something we must change; to what I'm not certain yet due to what I've written above. At the moment I tend to favor simply removing the version constraint.

The third point is something I must still investigate. Can you tell me on which distribution (I assume Debian) & version it happens?

ReillyBrogan · 2026-07-20T17:51:02Z

We got this working on AerynOS using a system utf8cpp with the following patch in case it's helpful:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index eb574bb..0aedbc8 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -48,7 +48,7 @@ function(add_cxx_flag_if_supported)
   endforeach()
 endfunction()
 
-find_package(utf8cpp 3.2.0)
+find_package(utf8cpp)
 if(NOT utf8cpp_FOUND)
   include(FetchContent REQUIRED)
   FetchContent_Declare(
@@ -138,7 +138,7 @@ if(WIN32)
   target_compile_definitions(ebml PRIVATE _CRT_SECURE_NO_WARNINGS)
 endif()
 
-target_link_libraries(ebml PRIVATE $<BUILD_INTERFACE:utf8cpp>)
+target_link_libraries(ebml PRIVATE utf8cpp::utf8cpp)
 
 if(CMAKE_VERSION VERSION_GREATER_EQUAL "3.20")
   if(${CMAKE_CXX_BYTE_ORDER} STREQUAL "BIG_ENDIAN")

robUx4 · 2026-07-21T08:53:42Z

The second point is something we must change; to what I'm not certain yet due to what I've written above. At the moment I tend to favor simply removing the version constraint.

The problem is that if there's a v5 that is incompatible with our code, the library may fail to build in the future. If we know that v4 works we could do something like:

find_package(utf8cpp 3.2.0)
if(NOT utf8cpp_FOUND)
    find_package(utf8cpp 4.0.0)
endif()

That also prevents building with v1 or v2 that may not work.

mbunkus · 2026-07-21T17:37:43Z

I've done some more testing & prepared an alternative PR in #346. Please give that one a try, too, and see its commit message for the rationale for my changes.

`find_package` with version constraint `3.2.0` does not consider 4.x.y to be compatible. Therefore also look for 4.x.y in a secondary `find_package` call. The fallback for cloning from git if neither version is found via `cmake` remains in place. Furthermore, linking against a distro-packaged 4.x.y doesn't seem to work with the existing `target_link_libraries(ebml PRIVATE $<BUILD_INTERFACE:utf8cpp>)` & requires `PRIVATE utf8cpp::utf8cpp`. However, that doesn't work with a git-cloned copy nor with distro-packaged 3.2.x as those still requires `PRIVATE $<BUILD_INTERFACE:utf8cpp>`. Therefore make the argument depend on the package detection, too. fixes #344 ; see #345

`find_package` with version constraint `3.2.0` does not consider 4.x.y to be compatible. Therefore also look for 4.x.y in a secondary `find_package` call. The fallback for cloning from git if neither version is found via `cmake` remains in place. Furthermore, linking against a distro-packaged 4.x.y doesn't seem to work with the existing `target_link_libraries(ebml PRIVATE $<BUILD_INTERFACE:utf8cpp>)` & requires `PRIVATE utf8cpp::utf8cpp`. However, that doesn't work with a git-cloned copy nor with distro-packaged 3.2.x as those still requires `PRIVATE $<BUILD_INTERFACE:utf8cpp>`. Therefore make the argument depend on availability of the `utf8cpp::utf8cpp` target: it is available only for distro-packaged 4.x.y. For the other two cases (distro-packaged < 4.x.y & cloned from git) we stay with `$<BUILD_INTERFACE:utf8cpp>`. fixes #344 ; see #345

mbunkus · 2026-07-24T06:50:12Z

fixed via #346 instead

Don't link with non-existant utf8cpp library

38920ad

mbunkus requested a review from robUx4 July 20, 2026 08:01

mbunkus mentioned this pull request Jul 21, 2026

fix detecting & using utf8c++ 4.0.0 or newer #346

Closed

mbunkus closed this Jul 24, 2026

Uh oh!

Conversation

marillat commented Jul 20, 2026

Uh oh!

mbunkus commented Jul 20, 2026

Uh oh!

marillat commented Jul 20, 2026

Uh oh!

robUx4 commented Jul 20, 2026

Uh oh!

mbunkus commented Jul 20, 2026

Uh oh!

robUx4 commented Jul 20, 2026

Uh oh!

robUx4 commented Jul 20, 2026

Uh oh!

mbunkus commented Jul 20, 2026

Uh oh!

robUx4 commented Jul 20, 2026

Uh oh!

robUx4 commented Jul 20, 2026

Uh oh!

mbunkus commented Jul 20, 2026

Uh oh!

marillat commented Jul 20, 2026

Uh oh!

mbunkus commented Jul 20, 2026

Uh oh!

marillat commented Jul 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

robUx4 commented Jul 20, 2026

Uh oh!

mbunkus commented Jul 20, 2026

Uh oh!

ReillyBrogan commented Jul 20, 2026

Uh oh!

robUx4 commented Jul 21, 2026

Uh oh!

mbunkus commented Jul 21, 2026

Uh oh!

mbunkus commented Jul 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

marillat commented Jul 20, 2026 •

edited

Loading