cppassimp/assimp #5005Reported task

Bug: Builld error when using assimp - include/assimp/types.h:79:13: fatal error: ../contrib/utf8cpp/source/utf8.h: No such file or directory

envgap__assimp__assimp-5005

Original GitHub issue ↗Dated source checkout ↗Opened 2023-03-10

01 / FAILURE SIGNATURE

Captured in a clean container

/opt/envgap-assimp/include/assimp/types.h:79:13: fatal error: ../contrib/utf8cpp/source/utf8.h: No such file or directory

02 / ENVIRONMENT RECIPE

Base commit: 60cefdd54927e79515563907887a1d9813d0b9b3
Manifest: CMakeLists.txt
Reproduce: cmake --build build -j2 && cmake --install build c++ -std=c++11 -I/opt/envgap-assimp/include -x c++ - -L/opt/envgap-assimp/lib -Wl,-rpath,/opt/envgap-assimp/lib -lassimp -lz -o build/envgap-consumer <<'ENVGAP_CPP' #include <assimp/Importer.hpp> #include <assimp/scene.h> #include <cstring> #include <iostream> int main() { const char *obj="v 0 0 0\nv 1 0 0\nv 0 1 0\nf 1 2 3\n"; Assimp::Importer importer; const aiScene *scene=importer.ReadFileFromMemory(obj, std::strlen(obj), 0, "obj"); if (!scene || scene->mNumMeshes != 1 || scene->mMeshes[0]->mNumVertices != 3) return 1; std::cout << "Imported one triangle through the installed Assimp library" << std::endl; } ENVGAP_CPP ./build/envgap-consumer
Run under trace: ./build/envgap-consumer

Reference environment fix used for admission

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 0f0e5a793..1de2911d4 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -846,3 +846,7 @@ if(WIN32)
     ENDIF()
   ENDIF()
 ENDIF ()
+
+# Install the UTF-8 headers referenced relatively by the public types.h header.
+install(DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/contrib/utf8cpp/source/"
+        DESTINATION "${ASSIMP_INCLUDE_INSTALL_DIR}/contrib/utf8cpp/source")

03 / ORIGINAL ISSUE TEXT

assimp/assimp #5005 · read the original issue

I have built assimp master from source (10th March 2023) and installed it into a local install directory and then build [vsgXchange](https://github.com/vsg-dev/vsgXchange) that uses assimp but vsgXchange now fails with the error:



```

 18%] Building CXX object src/CMakeFiles/vsgXchange.dir/openexr/openexr.cpp.o

In file included from /home/robert/Install/include/assimp/Importer.hpp:60,

                 from /home/robert/Dev/vsgXchange/src/assimp/assimp.cpp:21:

/home/robert/Install/include/assimp/types.h:79:13: fatal error: ../contrib/utf8cpp/source/utf8.h: No such file or directory

   79 | #   include "../contrib/utf8cpp/source/utf8.h"

      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

compilation terminated.



```



The utf8.h file is not installed by assimp's make install, so while assimp builds fine with the header in the local assimp/contrib/utf8cpp/source directory when building against the install assimp library the types.h that still references the relative path to the utf8.h fails.



I haven't walked back to older versions of assimp to see when this build regression occurred, but I know the previous stable release was working fine for me.



I presume with types.h will need to remove the offending include or have the utf8.h installed along with the rest of the assimp headers.

Continue on GitHub ↗

04 / LABELS

Labels checked by running the task · assistant reviewed

underspecification

Label rules and the text that matched

[
  {
    "category": "underspecification",
    "rule": "signature.missing_system_requirement",
    "source": "failure_signature",
    "excerpt": "/opt/envgap-assimp/include/assimp/types.h:79:13: fatal error: ../contrib/utf8cpp/source/utf8.h: No such file or directory"
  }
]

Historical install-only results are not EnvGap validation.

A small immutable consumer is supplied in the reproduction command, outside tracked upstream source. It imports one triangle through the installed Assimp library; no upstream source patch is allowed.

Only the OBJ importer is built to keep execution bounded; the affected public types.h and installation rules are unchanged. System zlib is an explicit prerequisite installed identically for original and gold.

Ubuntu package dependencies are not bounded to the issue date.

Preparation uses current registries. Historical package availability is not enforced here; execution metadata records this limitation separately from the oracle's date-bounding policy.