Build error for 9.10 on NetBSD

[mayureshw]

What version of OR-Tools and what language are you using? Version: 9.10 Language: C++

Which solver are you using (e.g. CP-SAT, Routing Solver, GLOP, BOP, Gurobi) Please see the dependencies I am building below.

What operating system (Linux, Windows, ...) and version? NetBSD 9.2 amd64

What did you do? Compile or-tools using pkgsrc framework

What did you expect to see Successful compilation

What did you see instead? Build error as attached.

Anything else we should know about your project / environment

Please see the list of dependencies I am including in the build (line 19-32 of the following Makefile) Makefile in the pkgsrc system

CMake Error at cmake/cpp.cmake:352 (target_link_libraries):
  Target "ortools" links to:

    Coin::CbcSolver

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.

Call Stack (most recent call first):
  CMakeLists.txt:425 (include)

CMake Error at ortools/graph/CMakeLists.txt:50 (target_link_libraries):
  Target "ortools_graph" links to:

    Coin::Cbc

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.

CMake Error at ortools/linear_solver/CMakeLists.txt:35 (target_link_libraries):
  Target "ortools_linear_solver" links to:

    Coin::Cbc

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.

CMake Error at ortools/gurobi/CMakeLists.txt:28 (target_link_libraries):
  Target "ortools_gurobi" links to:

    Coin::Cbc

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.

CMake Error at ortools/sat/CMakeLists.txt:31 (target_link_libraries):
  Target "ortools_sat" links to:

    Coin::Cbc

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.

CMake Generate step failed.  Build files cannot be regenerated correctly.

[Mizux]

you must provide a FindCbc.cmake so or-tools could find CoinOR's Cbc.... You can take a look at https://github.com/google/or-tools/blob/main/cmake/FindCbc.cmake

note: IIRC on main branch I've reworked the cmake dependencies check so it should be easier to test https://github.com/google/or-tools/blob/056cc989f3169cdfda3e03e90cd70dd5901a7f13/cmake/check_deps.cmake#L72-L80

ref: https://github.com/google/or-tools/commit/ade5661782a90dea351ead651870d1f3384ed520#diff-b120d8ef57d735bf6802010bd0a4da3ea7cdcdbaa7117e678c785a7c9a4b62f1

Otherwise you could also disable the CoinOR support using -DUSE_COINOR=OFF

[mayureshw]

FindCbc.cmake is already present in 9.10 and matches with the link you shared.

Regarding check_deps.cmake - what do I need to do to invoke it? (I am keeping the base code of 9.10 and just want to try adding this.)

With USE_COINOR=OFF, the error goes away, though not sure if I'd miss anything. This is a part of my effort to build OpenROAD and in turn openlane2.

[Mizux]

https://github.com/google/or-tools/blob/b39974ba209d9f5215bdc363bb8ad9625443d618/cmake/deps.cmake#L97-L119 here line 117 you could add the:

if(NOT TARGET Coin::CbcSolver)
  message(FATAL_ERROR "Target Coin::CbcSolver not available.")
endif()
if(NOT TARGET Coin::ClpSolver)
  message(FATAL_ERROR "Target Coin::ClpSolver not available.")
endif()

[mayureshw]

Thanks. I will revisit the above point. Now I find that the build is trying to fetch Abseil-cpp, even though it is installed as a dependency.

-- Fetching Abseil-cpp
--   Populating absl
CMake Error at /usr/pkg/share/cmake-3.30/Modules/ExternalProject/shared_internal_commands.cmake:951 (message):
  error: could not find git for clone of absl-populate
Call Stack (most recent call first):
  /usr/pkg/share/cmake-3.30/Modules/ExternalProject.cmake:3035 (_ep_add_download_command)
  CMakeLists.txt:29 (ExternalProject_Add)

-- Configuring incomplete, errors occurred!
CMake Error at /usr/pkg/share/cmake-3.30/Modules/FetchContent.cmake:1906 (message):
  CMake step for absl failed: 1
Call Stack (most recent call first):
  /usr/pkg/share/cmake-3.30/Modules/FetchContent.cmake:1609 (__FetchContent_populateSubbuild)
  /usr/pkg/share/cmake-3.30/Modules/FetchContent.cmake:2145:EVAL:2 (__FetchContent_doPopulation)
  /usr/pkg/share/cmake-3.30/Modules/FetchContent.cmake:2145 (cmake_language)
  /usr/pkg/share/cmake-3.30/Modules/FetchContent.cmake:2384 (__FetchContent_Populate)
  CMakeLists.txt:110 (FetchContent_MakeAvailable)

My cmake options are

CMAKE_CONFIGURE_ARGS+=  -DUSE_COINOR=OFF
CMAKE_CONFIGURE_ARGS+=  -DCMAKE_SYSTEM_NAME:STRING=${OPSYS}
CMAKE_CONFIGURE_ARGS+=  -DBUILD_absl=OFF
CMAKE_CONFIGURE_ARGS+=  -DBUILD_DEPS=OFF
CMAKE_CONFIGURE_ARGS+=  -DBUILD_EXAMPLES=OFF

PS: I have just searched FreeBSD in the code and made similar changes for NetBSD, in files: ortools/base/sysinfo.cc, ortools/util/fp_utils.h, ortools/util/zvector.h

[mayureshw]

Strangely, defining -DCMAKE_SYSTEM_NAME causes the issue of trying to build Abseil-cpp. For now I have removed -DCMAKE_SYSTEM_NAME

Now, there are errors related to use of VLOG_IS_ON in many source files.

For example,

/usr/pkgsrc/work/wip/or-tools/work/or-tools-9.10/ortools/pdlp/sharder.cc:117:13: error: 'VLOG_IS_ON' was no
t declared in this scope; did you mean 'VLOG_FIRST_N'?

Patching ortools/base/logging.h to include glog/vlog_is_on.h does not solve this.

Inclusion of above file requires defining GLOG_EXPORT. Defining this leads to several other errors, which I am not describing here. Wish to confirm if inclusion of glog/vlog_is_on.h should be needed first.

[Mizux]

In case of cross compiling we are also building abseil+protobuf to have protoc on the host machine in order to generate source file from .proto files.... see: https://github.com/google/or-tools/blob/4a2eaf5199edae73c08b89f37bad4ae481f3fd21/cmake/host.cmake#L14-L17

and according to the CMake doc:

This variable will be set to true by CMake if the CMAKE_SYSTEM_NAME variable has been set manually (i.e. in a toolchain file or as a cache entry from the cmake command line).

ref: https://cmake.org/cmake/help/latest/variable/CMAKE_CROSSCOMPILING.html

Thus, defining CMAKE_SYSTEM_NAME you'll also enable the CMAKE_CROSSCOMPILING to be TRUE thus making our cmake to build host tools aka protoc which need absl and protobuf....

[mayureshw]

I do not know if not setting CMAKE_SYSTEM_NAME would cause any problems. So far I didn't notice any.

Particularly, I hope VLOG_IS_ON problem described above is unrelated to this.

[Mizux]

IIRC VLOG_IS_ON was introduced in abseil-cpp AFTER the release of ortools v9.10 so you should try to use a more recent version of ortools to work with your installed version of abseil-cpp (try the branch mizux/rc or v99bugfix (incoming v9.11)) or use the exact same version than the one used by ortools at this time (note all abseil-cpp version are major/breaking change -_-)

see: https://github.com/google/or-tools/blob/v9.10/Dependencies.txt vs: https://github.com/google/or-tools/blob/v99bugfix/Dependencies.txt#L2

[mayureshw]

Thanks. v99bugfix builds with some patches - mostly following what is done for FreeBSD / OpenBSD, besides field name changes under fenv in fp_utils.

Would appreciate if you could incorporate.

$NetBSD$
--- ortools/base/sysinfo.cc.orig        2024-08-27 13:35:44.000000000 +0000
+++ ortools/base/sysinfo.cc
@@ -17,7 +17,7 @@
 #if defined(__APPLE__) && defined(__GNUC__)  // MacOS
 #include <mach/mach_init.h>
 #include <mach/task.h>
-#elif (defined(__FreeBSD__) || defined(__OpenBSD__))  // FreeBSD or OpenBSD
+#elif (defined(__FreeBSD__) || defined(__OpenBSD__)) || defined(__NetBSD__)  // FreeBSD or OpenBSD or NetBSD
 #include <sys/resource.h>
 #include <sys/time.h>
 // Windows
@@ -48,7 +48,7 @@ int64_t GetProcessMemoryUsage() {
   int64_t resident_memory = t_info.resident_size;
   return resident_memory;
 }
-#elif defined(__GNUC__) && !defined(__FreeBSD__) && !defined(__OpenBSD__) && \
+#elif defined(__GNUC__) && !defined(__FreeBSD__) && !defined(__OpenBSD__) && !defined(__NetBSD__) && \
     !defined(__EMSCRIPTEN__) && !defined(_WIN32)      // Linux
 int64_t GetProcessMemoryUsage() {
   unsigned size = 0;
@@ -61,7 +61,7 @@ int64_t GetProcessMemoryUsage() {
   fclose(pf);
   return int64_t{1024} * size;
 }
-#elif (defined(__FreeBSD__) || defined(__OpenBSD__))  // FreeBSD or OpenBSD
+#elif (defined(__FreeBSD__) || defined(__OpenBSD__) || defined(__NetBSD__))  // FreeBSD or OpenBSD or NetBSD
 int64_t GetProcessMemoryUsage() {
   int who = RUSAGE_SELF;
   struct rusage rusage;
$NetBSD$

--- ortools/util/fp_utils.h.orig        2024-08-27 13:35:44.000000000 +0000
+++ ortools/util/fp_utils.h
@@ -92,10 +92,16 @@ class ScopedFloatingPointEnv {
     fenv_.__control &= ~excepts;
 #elif (defined(__FreeBSD__) || defined(__OpenBSD__))
     fenv_.__x87.__control &= ~excepts;
+#elif (defined(__NetBSD__))
+    fenv_.x87.control &= ~excepts;
 #else  // Linux
     fenv_.__control_word &= ~excepts;
 #endif
+#if defined(__NetBSD__)
+    fenv_.mxcsr &= ~(excepts << 7);
+#else
     fenv_.__mxcsr &= ~(excepts << 7);
+#endif
     CHECK_EQ(0, fesetenv(&fenv_));
 #endif
   }
$NetBSD$

--- ortools/util/zvector.h.orig 2024-08-27 13:35:44.000000000 +0000
+++ ortools/util/zvector.h
@@ -14,7 +14,7 @@
 #ifndef OR_TOOLS_UTIL_ZVECTOR_H_
 #define OR_TOOLS_UTIL_ZVECTOR_H_

-#if (defined(__APPLE__) || defined(__FreeBSD__) || defined(__OpenBSD__)) && \
+#if (defined(__APPLE__) || defined(__FreeBSD__) || defined(__OpenBSD__) || defined(__NetBSD__) ) && \
     defined(__GNUC__)
 #include <machine/endian.h>
 #elif !defined(_MSC_VER) && !defined(__MINGW32__) && !defined(__MINGW64__)

[Mizux]

feel free to send us a PR against the main branch (our development branch)