Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[LIBC] Invalid token in LIBC_NAMESPACE macro expansion #125831

Closed
samvangysegem opened this issue Feb 5, 2025 · 7 comments · Fixed by #126193
Closed

[LIBC] Invalid token in LIBC_NAMESPACE macro expansion #125831

samvangysegem opened this issue Feb 5, 2025 · 7 comments · Fixed by #126193

Comments

@samvangysegem
Copy link
Contributor

samvangysegem commented Feb 5, 2025

When building the libc library based on the release/20.x branch, the compilation fails due to an invalid token in the LIBC_NAMESPACE macro expansion. This problem is rooted in the definition of LLVM_VERSION_SUFFIX

if(NOT DEFINED LLVM_VERSION_SUFFIX)
set(LLVM_VERSION_SUFFIX -rc1)
endif()

and its usage to configure the default_namespace field

set(default_namespace "__llvm_libc")
if(LLVM_VERSION_MAJOR)
set(default_namespace "__llvm_libc_${LLVM_VERSION_MAJOR}_${LLVM_VERSION_MINOR}_${LLVM_VERSION_PATCH}_${LLVM_VERSION_SUFFIX}")
endif()
set(LIBC_NAMESPACE ${default_namespace}
CACHE STRING "The namespace to use to enclose internal implementations. Must start with '__llvm_libc'."
)

For the release/20.x branch, LIBC_NAMESPACE is expanded to __llvm_libc_20_1_0_-rc1 with the invalid token -. This can be fixed relatively easy by either updating the LLVM_VERSION_SUFFIX definition to not use the - token or by removing the LLVM_VERSION_SUFFIX from the libc default_namespace.

@llvmbot llvmbot added the libc label Feb 5, 2025
@llvmbot
Copy link
Member

llvmbot commented Feb 5, 2025

@llvm/issue-subscribers-libc

Author: s.vgys (samvangysegem)

When building the libc library based on the `release/20.x`, the compilation fails due to an invalid token in the LIBC_NAMESPACE macro expansion. This problem is rooted in the definition of `LLVM_VERSION_SUFFIX` in the `cmake/Modules/LLVMVersion.cmake` file: ``` if(NOT DEFINED LLVM_VERSION_SUFFIX) set(LLVM_VERSION_SUFFIX -rc1) endif() ``` and its usage in `libc/CMakeLists.txt` to configure the `default_namespace` field as shown below: ``` # Defining a global namespace to enclose all libc functions. set(default_namespace "__llvm_libc") if(LLVM_VERSION_MAJOR) set(default_namespace "__llvm_libc_${LLVM_VERSION_MAJOR}_${LLVM_VERSION_MINOR}_${LLVM_VERSION_PATCH}_${LLVM_VERSION_SUFFIX}") endif() set(LIBC_NAMESPACE ${default_namespace} CACHE STRING "The namespace to use to enclose internal implementations. Must start with '__llvm_libc'." ) ``` For the `release/20.x` branch, `LIBC_NAMESPACE` is expanded to `__llvm_libc_20_1_0_-rc1` with the invalid token `-`. This can be fixed relatively easy by either updating the `LLVM_VERSION_SUFFIX` definition to not use the `-` token or by removing the `LLVM_VERSION_SUFFIX` from the libc default_namespace.

@nickdesaulniers
Copy link
Member

Thanks for the report! It sounds like we could use cmakes's string(REPLACE functionality on LLVM_VERSION_SUFFIX to replace - with ``.

@nickdesaulniers nickdesaulniers added good first issue https://github.com/llvm/llvm-project/contribute build-problem labels Feb 5, 2025
@llvmbot
Copy link
Member

llvmbot commented Feb 5, 2025

Hi!

This issue may be a good introductory issue for people new to working on LLVM. If you would like to work on this issue, your first steps are:

  1. Check that no other contributor has already been assigned to this issue. If you believe that no one is actually working on it despite an assignment, ping the person. After one week without a response, the assignee may be changed.
  2. In the comments of this issue, request for it to be assigned to you, or just create a pull request after following the steps below. Mention this issue in the description of the pull request.
  3. Fix the issue locally.
  4. Run the test suite locally. Remember that the subdirectories under test/ create fine-grained testing targets, so you can e.g. use make check-clang-ast to only run Clang's AST tests.
  5. Create a Git commit.
  6. Run git clang-format HEAD~1 to format your changes.
  7. Open a pull request to the upstream repository on GitHub. Detailed instructions can be found in GitHub's documentation. Mention this issue in the description of the pull request.

If you have any further questions about this issue, don't hesitate to ask via a comment in the thread below.

@llvmbot
Copy link
Member

llvmbot commented Feb 5, 2025

@llvm/issue-subscribers-good-first-issue

Author: s.vgys (samvangysegem)

When building the libc library based on the `release/20.x` branch, the compilation fails due to an invalid token in the LIBC_NAMESPACE macro expansion. This problem is rooted in the definition of `LLVM_VERSION_SUFFIX`

if(NOT DEFINED LLVM_VERSION_SUFFIX)
set(LLVM_VERSION_SUFFIX -rc1)
endif()

and its usage to configure the default_namespace field

set(default_namespace "__llvm_libc")
if(LLVM_VERSION_MAJOR)
set(default_namespace "__llvm_libc_${LLVM_VERSION_MAJOR}_${LLVM_VERSION_MINOR}_${LLVM_VERSION_PATCH}_${LLVM_VERSION_SUFFIX}")
endif()
set(LIBC_NAMESPACE ${default_namespace}
CACHE STRING "The namespace to use to enclose internal implementations. Must start with '__llvm_libc'."
)

For the release/20.x branch, LIBC_NAMESPACE is expanded to __llvm_libc_20_1_0_-rc1 with the invalid token -. This can be fixed relatively easy by either updating the LLVM_VERSION_SUFFIX definition to not use the - token or by removing the LLVM_VERSION_SUFFIX from the libc default_namespace.

@samvangysegem
Copy link
Contributor Author

Sounds good! I'll make a PR with the fix.

@samvangysegem
Copy link
Contributor Author

@nickdesaulniers Could we mark this issue to be included in the next patch release for the release/20.x branch? Then I can add the cherry-pick message for backporting...

@nickdesaulniers
Copy link
Member

done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging a pull request may close this issue.

3 participants