include 'Debug' version of 'ortools.lib' in 'ortools' release packages

[brunodema]

What language and solver does this apply to? C++ with CMake/Visual Studio Community 2019

Describe the problem you are trying to solve. I'm currently developing a library which consumes 'ortools'. Since I need to debug my own code in order to test it, I need to link the 'ortools' libraries using a Debug version. However, it seems that all releases under the v8.1 tag that include a built 'ortools.lib' file that was compiled in Release mode, which causes errors when trying to compile my code in Debug mode. My CMake script currently fetches a v8.1 release package from this repository, which contains only one version of the 'ortools' static library (Release).

Describe the solution you'd like I'd like only to ask for the inclusion of a Debug version of the static library, alongside the Release version, in 'ortools' release packages.

Describe alternatives you've considered One valid alternative for my problem is to declare 'ortools' as a dependency of my project and compile it together with my code ('fetchcontent'). However, compiling the entirety of 'ortools' takes way too long for this to be worth it. I believe that adding a Debug version together with the release files would help many other people who are also trying to run Debug versions of their own code.

Additional context (Pretty much common errors related to mixed Debug/Release builds)

[Mizux]

Currently, archives are generated using the Makefile based build which can't build debug version easily.

Migrating to a CMake based artifacts should ease the creation of a Debug version... In the meantime, instead of integrating or-tools using FetchContent (like here)

You could try to build it in Debug , install it in a local directory and zip it to later use, so you won't have to rebuild it each time but simply reuse this archive...

[brunodema]

Thank you very much for your reply, Mizux.

Just to give more context on my case, I'd like first to state that I have much to learn about C++ in general, so my real issues with this might be misplaced. My main CMake script is currently set as this:

include(FetchContent)
set(FETCHCONTENT_QUIET FALSE)
set(BUILD_DEPS ON) # this is a 'ortools' option definition
FetchContent_Declare(ortools URL ${${CMAKE_SYSTEM_NAME}_ORTOOLS_URL})
# After the following call, the CMake targets defined by or-tools will be
# defined and available to the rest of the build
FetchContent_MakeAvailable(ortools)

where ${CMAKE_SYSTEM_NAME}_ORTOOLS_URL} will target either the release package for Windows or Ubuntu. This was my way to simplify the dependency build process, by only consuming an already built library. Unfortunately, as I said, there is only a release version of the libraries, which causes my current issues.

I only recently discovered that it is not possible (or recommended) to mix different build modes (i.e. Debug and Release), since they cause the aforementioned errors. In my experience with C++ and Gurobi in general, I only consumed the solver's Debug libraries, but I didn't notice that at that time, meaning that I could've learned about this situation earlier.

Since I already have installed and compiled the 'ortools' library before on my PC, I just reran the scripts to generate a Debug version of it. I tried both (1) copying the '.lib' inside the determined place for it in my repo/build, and (2) setting the output folder of the Debug build of 'ortools' library (where all '.o','.ilk','.pdb' files are also too). I still continued getting link errors in Visual Studio:

This prompted me to imagine that some manual configuration of the library could be causing this, but given my short time with 'ortools', I am not sure if this is an accurate guess or not. I already managed to debug my code in Ubuntu using the release version of the library for the system. VSCode/CMake outputs the following when running CMake:

[proc] Executing command: /usr/bin/cmake --no-warn-unused-cli -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_C_COMPILER:FILEPATH=/bin/gcc-9 -DCMAKE_CXX_COMPILER:FILEPATH=/bin/g++-9 -H/workspaces/OR2LaTeX -B/workspaces/OR2LaTeX/build -G "Unix Makefiles"

I only moved to Visual Studio because I wanted to have a better debugging envrionment (better UI, see threads, see pointers, etc). Either way, my goal is to debug my own code, not 'ortools' code. I do not mind consuming the library build in Release mode, it is just that I recently learned that apparently mixing configurations cause problems.

If there is any other info that I can supply you in order to help you, please let me know.

[Mizux]

Few things:

1. These prebuilt archives have been done using the Makefile build system so they won't contains any CMake config or CMakeLists.txt files, so I'm really curious how it can work with FetchContent()
   • Using the git repo url it should works as you can see in my previous link...
2. Maybe i'm wrong, but your trace recall me a bug concerning the C++ dialect use -> Are you building your lib using C++17 ? TLDR absl headers won't generate same symbols depending on the C++ dialect use, and or-tools use/force C++17 (i.e. it will read absl headers using C++17 which will generate C++17 symbols). That could explain the missing symbols.
3. I'll try to generate a debug version of ortools in my Windows10 VM and let you know...

[brunodema]

Yes, I am currently enforcing C++ 17 on my library, otherwise absl implementation will cause errors (https://github.com/abseil/abseil-cpp/issues/649 and https://github.com/abseil/abseil-cpp/issues/847). What is weird is that I only started doing this once I began to support cross-compilation on Windows... I was actually able to compile my code using C++ 20 on Ubuntu 20.04.

Last night I came to a compromise by being able to debug my code while consuming 'ortools' using a RelWithDebugInfo build. This was not ideal, since some parts of my code suffered optimizations and could not be visualized (like this pointers). Whenever I used FetchContent(), I always followed the structure pointed out by you and on here, only adding a few extra flags for verbosity (git progress). I will try again to use 'ortools' as a FetchContent direct dependency and see what happens.

[brunodema]

I just wanted to clarify this, in case I understood it correctly:

These prebuilt archives have been done using the Makefile build system so they won't contains any CMake config or CMakeLists.txt files, so I'm really curious how it can work with FetchContent()

What my FetchContent() does is to simply download the compacted files provided by the URL (like this one), and extract them inside 'ortools-src'. I later use find_* to set the path of ortools.lib and of the include directories. I do not run any build commands, I just consume the pre-built release library.

[juntek]

@brunodema please take a look at my comment https://github.com/google/or-tools/issues/2335#issuecomment-773600256 on how to build debug version for yourself

[brunodema]

I actually am not have any major issues compiling 'ortools' in Debug mode... my real issues were linking my Debug mode code with the pre-built release libraries (which was a conceptual error from my part). My request is motivated by the fact that many libraries release packages with multiple Debug/Release compilation configurations (...md.dll, ...mt.dll, ...mdd.dll, .mtd.dll), which allows other libraries to consume the pre-built libraries, and to link them in any way they wish.

[lperron]

With the cmake build, you can build in debug easily. DEBUG libraries are too big for delivery.

[TheTimDev]

I am running into the same issue, using Win10 and the MSVC 2017 compiler and ortools 9.5. When building ortools in DEBUG mode, the resulting .lib files contain symbols, identifying them as release builds (ITERATOR_DEBUG_LEVEL=0 and RunTimeLibrary=MdDynamicRelease). As long as those symbols are present, ortools will not link with a library build in Debug mode. I am using the CMake pipeline, and as far as I understand the problem originates in a dependency of ortools, namely protobuf. That library still seems to be build with a release configuration, ignoring the CMake build instructions.

[Mizux]

I am running into the same issue, using Win10 and the MSVC 2017 compiler and ortools 9.5. When building ortools in DEBUG mode, the resulting .lib files contain symbols, identifying them as release builds (ITERATOR_DEBUG_LEVEL=0 and RunTimeLibrary=MdDynamicRelease). As long as those symbols are present, ortools will not link with a library build in Debug mode. I am using the CMake pipeline, and as far as I understand the problem originates in a dependency of ortools, namely protobuf. That library still seems to be build with a release configuration, ignoring the CMake build instructions.

Did you try with MSVC 2022 and last release ? nor or-tools nor Protobuf will fix older release (aka "live at head" for the worse and the...)

[TheTimDev]

Sadly the Project I am working on does not allow for a newer Version of MSVC than 2019 (with which it also did not work). Maybe at some point in the future I can switch to 2022 and the latest ortools. But thank you very much for replying :-)