github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-06 16:11:34 -05:00
Code Issues 14.5k Packages Projects Releases 120 Wiki Activity

[GH-ISSUE #12872] Ollama 0.11.3 or later fails to build with CUDA, can't find math.h in #include_next (fixed with work around) #55040

New Issue
Closed
opened 2026-04-29 08:14:13 -05:00 by GiteaMirror · 6 comments
GiteaMirror commented 2026-04-29 08:14:13 -05:00
Owner
Copy Link

Originally created by @abcbarryn on GitHub (Oct 30, 2025).
Original GitHub issue: https://github.com/ollama/ollama/issues/12872

Originally assigned to: @dhiltgen on GitHub.

What is the issue?

The error message is:

/usr/include/c++/14/cmath:47:15: fatal error: math.h: No such file or directory
   47 | #include_next <math.h>
      |               ^~~~~~~~

Ollama version 0.11.2 or earlier compiles correctly.
This is probably due to changes in the CMakeLists.txt file or something changing the order of the include path.
The #include_next directive is a GNU extension to the C preprocessor that instructs the preprocessor to search for the specified header file in the include path, starting from the directory after the one where the current file was found. The "file not found" error with #include_next indicates that the preprocessor could not locate the desired file in the subsequent directories within the include path.
Here are some potential causes and solutions for this issue:
Incorrect Include Path Configuration:
The most common reason is that the necessary directories containing the target header file are not correctly added to the compiler's include path.
If using a build system like CMake, ensure that include flags and paths are not being inadvertently overridden or misconfigured within the build recipes or CMakeLists.txt files.

Relevant log output

nvcc warning : The 'compute_35', 'compute_37', 'sm_35', and 'sm_37' architectures are deprecated, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning).
In file included from /usr/local/cuda/include/crt/math_functions.h:10551,
                 from /usr/local/cuda/include/crt/common_functions.h:303,
                 from /usr/local/cuda/include/cuda_runtime.h:115,
                 from <command-line>:
/usr/include/c++/14/cmath:47:15: fatal error: math.h: No such file or directory
   47 | #include_next <math.h>
      |               ^~~~~~~~
compilation terminated.
gmake[2]: *** [ml/backend/ggml/ggml/src/ggml-cuda/CMakeFiles/ggml-cuda.dir/build.make:80: ml/backend/ggml/ggml/src/ggml-cuda/CMakeFiles/ggml-cuda.dir/acc.cu.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:773: ml/backend/ggml/ggml/src/ggml-cuda/CMakeFiles/ggml-cuda.dir/all] Error 2
gmake: *** [Makefile:136: all] Error 2

OS

Linux

GPU

Nvidia

CPU

Intel

Ollama version

0.11.3 up to and including 0.12.7

Originally created by @abcbarryn on GitHub (Oct 30, 2025). Original GitHub issue: https://github.com/ollama/ollama/issues/12872 Originally assigned to: @dhiltgen on GitHub. ### What is the issue? The error message is: ``` /usr/include/c++/14/cmath:47:15: fatal error: math.h: No such file or directory 47 | #include_next <math.h> | ^~~~~~~~ ``` Ollama version 0.11.2 or earlier compiles correctly. This is probably due to changes in the CMakeLists.txt file or something changing the order of the include path. The #include_next directive is a GNU extension to the C preprocessor that instructs the preprocessor to search for the specified header file in the include path, starting from the directory after the one where the current file was found. The "file not found" error with #include_next indicates that the preprocessor could not locate the desired file in the subsequent directories within the include path. Here are some potential causes and solutions for this issue: Incorrect Include Path Configuration: The most common reason is that the necessary directories containing the target header file are not correctly added to the compiler's include path. If using a build system like CMake, ensure that include flags and paths are not being inadvertently overridden or misconfigured within the build recipes or CMakeLists.txt files. ### Relevant log output ```shell nvcc warning : The 'compute_35', 'compute_37', 'sm_35', and 'sm_37' architectures are deprecated, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning). In file included from /usr/local/cuda/include/crt/math_functions.h:10551, from /usr/local/cuda/include/crt/common_functions.h:303, from /usr/local/cuda/include/cuda_runtime.h:115, from <command-line>: /usr/include/c++/14/cmath:47:15: fatal error: math.h: No such file or directory 47 | #include_next <math.h> | ^~~~~~~~ compilation terminated. gmake[2]: *** [ml/backend/ggml/ggml/src/ggml-cuda/CMakeFiles/ggml-cuda.dir/build.make:80: ml/backend/ggml/ggml/src/ggml-cuda/CMakeFiles/ggml-cuda.dir/acc.cu.o] Error 1 gmake[1]: *** [CMakeFiles/Makefile2:773: ml/backend/ggml/ggml/src/ggml-cuda/CMakeFiles/ggml-cuda.dir/all] Error 2 gmake: *** [Makefile:136: all] Error 2 ``` ### OS Linux ### GPU Nvidia ### CPU Intel ### Ollama version 0.11.3 up to and including 0.12.7
GiteaMirror added the buildbuglinux labels 2026-04-29 08:14:14 -05:00
GiteaMirror commented 2026-04-29 08:14:16 -05:00
Author
Owner
Copy Link

@abcbarryn commented on GitHub (Nov 5, 2025):

This indicates a breaking change in how header files are handled in the 0.11.3 version, likely related to a new compiler or build system configuration. The need to manually edit header files to resolve the #include_next issue strongly suggests a regression in the build process.

<!-- gh-comment-id:3494021336 --> @abcbarryn commented on GitHub (Nov 5, 2025): This indicates a breaking change in how header files are handled in the 0.11.3 version, likely related to a new compiler or build system configuration. The need to manually edit header files to resolve the `#include_next` issue strongly suggests a regression in the build process.
GiteaMirror commented 2026-04-29 08:14:16 -05:00
Author
Owner
Copy Link

@abcbarryn commented on GitHub (Nov 5, 2025):

The fact that the #include_next issue affects any version 0.11.3 or later, and that 0.11.2 works flawlessly, dramatically narrows the scope of the regression. It points to a fundamental change in how header file inclusion is handled somewhere between those versions.

<!-- gh-comment-id:3494034416 --> @abcbarryn commented on GitHub (Nov 5, 2025): The fact that the `#include_next` issue affects *any* version 0.11.3 or later, and that 0.11.2 works flawlessly, dramatically narrows the scope of the regression. It points to a fundamental change in how header file inclusion is handled somewhere between those versions.
GiteaMirror commented 2026-04-29 08:14:17 -05:00
Author
Owner
Copy Link

@abcbarryn commented on GitHub (Nov 5, 2025):

Subject: Importance of Addressing Regressions Affecting Specific Library/Compiler Versions

Team,

We're experiencing a regression in recent Ollama versions (0.11.3 and later) that is preventing builds with certain compiler/library configurations. While seemingly niche, it’s critically important to address this issue, even if it doesn’t impact all users.

Here's why:

  • Hidden Dependencies: This regression highlights the often-hidden dependencies within software. Changes seemingly isolated to internal code can have unforeseen consequences on seemingly unrelated areas, particularly when interacting with external libraries or compiler versions.
  • Maintainability & Stability: Ignoring regressions, even those affecting a smaller segment of users, compromises the overall maintainability and long-term stability of the project. Unaddressed regressions create technical debt and increase the risk of future, more widespread issues.
  • User Experience: Even a small number of affected users experience a significant disruption to their workflow. Failing to address these issues negatively impacts their experience and diminishes trust in the project.
  • Future-Proofing: Allowing compiler/library-specific regressions to persist limits the project’s ability to adapt to future changes in the software ecosystem.
  • Community Reputation: Responding promptly and effectively to community feedback, especially regarding regressions, strengthens the project's reputation and fosters a culture of collaboration.

Addressing this seemingly narrow issue serves as a valuable opportunity to reinforce best practices for regression testing, dependency management, and code maintainability. It's a vital step towards ensuring the continued health and success of the Ollama project.

<!-- gh-comment-id:3494053582 --> @abcbarryn commented on GitHub (Nov 5, 2025): **Subject: Importance of Addressing Regressions Affecting Specific Library/Compiler Versions** Team, We're experiencing a regression in recent Ollama versions (0.11.3 and later) that is preventing builds with certain compiler/library configurations. While seemingly niche, it’s critically important to address this issue, even if it doesn’t impact all users. Here's why: * **Hidden Dependencies:** This regression highlights the often-hidden dependencies within software. Changes seemingly isolated to internal code can have unforeseen consequences on seemingly unrelated areas, particularly when interacting with external libraries or compiler versions. * **Maintainability & Stability:** Ignoring regressions, even those affecting a smaller segment of users, compromises the overall maintainability and long-term stability of the project. Unaddressed regressions create technical debt and increase the risk of future, more widespread issues. * **User Experience:** Even a small number of affected users experience a significant disruption to their workflow. Failing to address these issues negatively impacts their experience and diminishes trust in the project. * **Future-Proofing:** Allowing compiler/library-specific regressions to persist limits the project’s ability to adapt to future changes in the software ecosystem. * **Community Reputation:** Responding promptly and effectively to community feedback, especially regarding regressions, strengthens the project's reputation and fosters a culture of collaboration. Addressing this seemingly narrow issue serves as a valuable opportunity to reinforce best practices for regression testing, dependency management, and code maintainability. It's a vital step towards ensuring the continued health and success of the Ollama project.
GiteaMirror commented 2026-04-29 08:14:17 -05:00
Author
Owner
Copy Link

@abcbarryn commented on GitHub (Nov 11, 2025):

Still having this issue unless I edit the system include files /usr/include/c++/11/bits/std_abs.h /usr/include/c++/11/cstdlib /usr/include/c++/11/cmath and change #include_next to #include...

nvcc warning : Support for offline compilation for architectures prior to '<compute/sm/lto>_75' will be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning).
In file included from /usr/local/cuda/include/crt/math_functions.h:4581,
                 from /usr/local/cuda/include/crt/common_functions.h:303,
                 from /usr/local/cuda/include/cuda_runtime.h:117,
                 from <command-line>:
/usr/include/c++/11/cmath:45:15: fatal error: math.h: No such file or directory
   45 | #include_next <math.h>
      |               ^~~~~~~~
compilation terminated.
gmake[2]: *** [ml/backend/ggml/ggml/src/ggml-cuda/CMakeFiles/ggml-cuda.dir/build.make:80: ml/backend/ggml/ggml/src/ggml-cuda/CMakeFiles/ggml-cuda.dir/acc.cu.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:801: ml/backend/ggml/ggml/src/ggml-cuda/CMakeFiles/ggml-cuda.dir/all] Error 2
gmake: *** [Makefile:136: all] Error 2
<!-- gh-comment-id:3517437605 --> @abcbarryn commented on GitHub (Nov 11, 2025): Still having this issue unless I edit the system include files /usr/include/c++/11/bits/std_abs.h /usr/include/c++/11/cstdlib /usr/include/c++/11/cmath and change #include_next to #include... ``` nvcc warning : Support for offline compilation for architectures prior to '<compute/sm/lto>_75' will be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning). In file included from /usr/local/cuda/include/crt/math_functions.h:4581, from /usr/local/cuda/include/crt/common_functions.h:303, from /usr/local/cuda/include/cuda_runtime.h:117, from <command-line>: /usr/include/c++/11/cmath:45:15: fatal error: math.h: No such file or directory 45 | #include_next <math.h> | ^~~~~~~~ compilation terminated. gmake[2]: *** [ml/backend/ggml/ggml/src/ggml-cuda/CMakeFiles/ggml-cuda.dir/build.make:80: ml/backend/ggml/ggml/src/ggml-cuda/CMakeFiles/ggml-cuda.dir/acc.cu.o] Error 1 gmake[1]: *** [CMakeFiles/Makefile2:801: ml/backend/ggml/ggml/src/ggml-cuda/CMakeFiles/ggml-cuda.dir/all] Error 2 gmake: *** [Makefile:136: all] Error 2 ```
GiteaMirror commented 2026-04-29 08:14:18 -05:00
Author
Owner
Copy Link

@abcbarryn commented on GitHub (Nov 13, 2025):

Subject: CRITICAL: Ollama Build Failure - Requires System File Edits!

Hi Team,

We're seeing a critical regression that's blocking builds of Ollama.
Currently, the build process fails because the system can't find math.h
during compilation. The error message specifically points to issues with
#include_next directives.

The Problem:

The only known workaround at the moment is to manually edit system include
files (specifically, /usr/include/c++/11/bits/std_abs.h,
/usr/include/c++/11/cstdlib, and /usr/include/c++/11/cmath) and change
#include_next to a standard #include.

Why This Is A Big Deal:

  • Builds Are Broken: This is preventing users from building and
    using Ollama.
  • Unstable Solution: Modifying system files directly is a dangerous
    workaround – it risks destabilizing the system and can lead to unexpected
    conflicts.
  • Reproducibility Nightmare: This makes builds unpredictable and
    difficult to reproduce, which is a major problem for developers and
    contributors.
  • Bad User Experience: This creates a frustrating and unusable
    experience for anyone trying to build Ollama.

What We Need:

This regression needs immediate attention. We need to identify the root
cause and implement a proper fix that doesn't rely on modifying system
include files. This isn’t a sustainable solution, and it's impacting the
usability and reliability of the project.

Please treat this as a high-priority issue. Any insights or progress
updates would be greatly appreciated.

<!-- gh-comment-id:3526542552 --> @abcbarryn commented on GitHub (Nov 13, 2025): **Subject: CRITICAL: Ollama Build Failure - Requires System File Edits!** Hi Team, We're seeing a critical regression that's blocking builds of Ollama. Currently, the build process fails because the system can't find `math.h` during compilation. The error message specifically points to issues with `#include_next` directives. **The Problem:** The only known workaround at the moment is to manually edit system include files (specifically, `/usr/include/c++/11/bits/std_abs.h`, `/usr/include/c++/11/cstdlib`, and `/usr/include/c++/11/cmath`) and change `#include_next` to a standard `#include`. **Why This Is A Big Deal:** * **Builds Are Broken:** This is preventing users from building and using Ollama. * **Unstable Solution:** Modifying system files directly is a dangerous workaround – it risks destabilizing the system and can lead to unexpected conflicts. * **Reproducibility Nightmare:** This makes builds unpredictable and difficult to reproduce, which is a major problem for developers and contributors. * **Bad User Experience:** This creates a frustrating and unusable experience for anyone trying to build Ollama. **What We Need:** This regression needs immediate attention. We need to identify the root cause and implement a proper fix that doesn't rely on modifying system include files. This isn’t a sustainable solution, and it's impacting the usability and reliability of the project. Please treat this as a high-priority issue. Any insights or progress updates would be greatly appreciated.
GiteaMirror commented 2026-04-29 08:14:19 -05:00
Author
Owner
Copy Link

@abcbarryn commented on GitHub (Nov 16, 2025):

Ok, I got it to build using these settings...

export CMAKE_CUDA_COMPILER=/usr/local/cuda/bin/nvcc
export PATH="/usr/local/cuda/nvvm/bin:/usr/local/cuda/bin:/usr/local/cuda/lib64:/sbin:/usr/sbin:/usr/bin:/bin"
export LD_LIBRARY_PATH="/lib64:/usr/lib64:/usr/local/cuda/lib64:/usr/local/cuda/targets/x86_64-linux/lib"
cmake -B build -DCMAKE_CUDA_COMPILER="$CMAKE_CUDA_COMPILER"
cmake --build build

I had to add the -DCMAKE_CUDA_COMPILER="$CMAKE_CUDA_COMPILER" to the cmake command and set the path for cmake to properly find the CUDA compiler. I removed export INCLUDES="-I /usr/local/cuda/include" which was causing this issue
Using CUDA 12.9 with my GPU, it grumbles: nvcc warning : Support for offline compilation for architectures prior to '<compute/sm/lto>_75' will be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning). but it compiles.

<!-- gh-comment-id:3538509446 --> @abcbarryn commented on GitHub (Nov 16, 2025): Ok, I got it to build using these settings... ``` export CMAKE_CUDA_COMPILER=/usr/local/cuda/bin/nvcc export PATH="/usr/local/cuda/nvvm/bin:/usr/local/cuda/bin:/usr/local/cuda/lib64:/sbin:/usr/sbin:/usr/bin:/bin" export LD_LIBRARY_PATH="/lib64:/usr/lib64:/usr/local/cuda/lib64:/usr/local/cuda/targets/x86_64-linux/lib" cmake -B build -DCMAKE_CUDA_COMPILER="$CMAKE_CUDA_COMPILER" cmake --build build ``` I had to add the -DCMAKE_CUDA_COMPILER="$CMAKE_CUDA_COMPILER" to the cmake command and set the path for cmake to properly find the CUDA compiler. I removed `export INCLUDES="-I /usr/local/cuda/include"` which was causing this issue Using CUDA 12.9 with my GPU, it grumbles: `nvcc warning : Support for offline compilation for architectures prior to '<compute/sm/lto>_75' will be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning).` but it compiles.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label bug build linux
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#55040
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?