GithubHelp home page GithubHelp logo

llvm-bazel's Introduction

LLVM Bazel BUILD files

DISCLAIMER: This has been superseded by the Bazel build configuration in the LLVM Project monorepo. This is not an officially-supported Google project, and we don't plan continued maintenance of it.

This repo contains standalone Bazel BUILD configuration for part of the LLVM project that could be shared by dependent projects using the Bazel build system.

It is similar to the BUILD files for LLVM and MLIR in the TensorFlow project, but aims to be suitable for more general usage.

Status

This build configuration has now been migrated upstream to the LLVM monorepo, in a side directory. This is following the upstreaming proposal. Therefore this repository is no longer actively updated. Please prefer the upstream build files which will see regular maintenance. Transitioning to those should be straightforward and you can find usage examples there. We may continue to accept PRs updating this repository until projects have time to migrate, but will not be updating it ourselves.

Usage

These build files are flexible in how they can be used. The llvm-bazel subdirectory has the simplest build configuration with a submodule for the llvm-project. The WORKSPACE is in that directory, so you can build the project like:

cd llvm-bazel/
bazel build --config=generic_clang @llvm-project//...

Users are more likely going to want to fetch build files from this repository and use them with their own copy of the llvm-project.

The http-archive-demo branch shows a build based on http_archive.

The submodule-demo branch shows usage of these build files with both them and llvm-project coming from submodules.

You can build either of these demos after changing into the respective directory with a command like

bazel build --config=generic_clang @llvm-project//...

License

Licensed under the Apache license with LLVM Exceptions. See LICENSE for more information.

llvm-bazel's People

Contributors

cdleary avatar chandlerc avatar chiahungduan avatar chriscummins avatar ftynse avatar gmngeoffrey avatar hanhanw avatar kooljblack avatar mmcloughlin avatar mztriz avatar natashaknk avatar not-jenni avatar rrbutani avatar rsuderman avatar scentini avatar scotttodd avatar thomasraoux avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

llvm-bazel's Issues

Add an LLD cc_binary target to OSS llvm-bazel

We need to build lld as part of our toolchain (alongside other binaries like llvm-ar and mlir-tblgen). This is currently missing in the llvm-bazel open source release but seems to exist inside of google (though it may require some untangling).

Tags corresponding to LLVM releases

(Sorry, me again!)

It seems to me a common use case for many users would be building a specific LLVM release. However, I'm not sure this is always possible with the current setup, please correct me if I'm wrong.

For example, LLVM 11.1.0 was tagged at llvm/llvm-project@1fdec59. But there is no corresponding tag in this repository:

https://github.com/google/llvm-bazel/tree/llvm-project-1fdec59bffc11ae37eb51a1b9869f0696bfd5312

I'm guessing this is because the auto-integration step only considers commits on main, and this tag is on a release branch?

I'm not sure how hard it is, but it would be awesome if this repo contained versions for LLVM releases. Like llvm-project-<tag> corresponding to llvm/llvm-project@<tag>.

http-archive-demo broken

$ cd /tmp
$ git clone https://github.com/google/llvm-bazel.git
$ git checkout -b demo origin/http-archive-demo
$ cd http-archive-demo
$ bazel-3.3.1 build @llvm-project//clang
...
<huge warning spew>

ability to statically link clang?

I'm not super familiar with blaze build rules, but it looks like for cc_binary linkstatic is default True link, but builds of clang via:

$ bazel-3.3.1 build --config=generic_clang @llvm-project//clang
$ llvm-readelf -d ./bazel-bin/external/llvm-project/clang/clang | grep NEEDED
  0x0000000000000001 (NEEDED)       Shared library: [libstdc++.so.6]
  0x0000000000000001 (NEEDED)       Shared library: [libm.so.6]
  0x0000000000000001 (NEEDED)       Shared library: [libdl.so.2]
  0x0000000000000001 (NEEDED)       Shared library: [libgcc_s.so.1]
  0x0000000000000001 (NEEDED)       Shared library: [libpthread.so.0]
  0x0000000000000001 (NEEDED)       Shared library: [libc.so.6]
  0x0000000000000001 (NEEDED)       Shared library: [ld-linux-x86-64.so.2]

is there something changing the implicit default? Is there a way to force linkstatic?

diff --git a/llvm-bazel/llvm-project-overlay/clang/BUILD.bazel b/llvm-bazel/llvm-project-overlay/clang/BUILD.bazel
index 263cf421a1d4..cc9c41d38f65 100644
--- a/llvm-bazel/llvm-project-overlay/clang/BUILD.bazel
+++ b/llvm-bazel/llvm-project-overlay/clang/BUILD.bazel
@@ -1909,6 +1909,7 @@ cc_binary(
     deps = [
         ":clang-driver",
     ],
+    linkstatic = 1,
 )
 
 cc_binary(

doesn't seem to do anything.

Bazel doesn't check for supported features like mallinfo while upstream LLVM does

In an effort to get Tensorflow working on Alpine Linux with Musl libc (instead of glibc), I encountered an issue while it compiled LLVM:

ERROR: /home/bart/.cache/bazel/_bazel_bart/f5cee94bd62e1be0d824a974250af519/external/llvm-project/llvm/BUILD:3766:11: C++ compilation of rule '@llvm-project//llvm:Support' failed (Exit 1)
In file included from external/llvm-project/llvm/lib/Support/Process.cpp:101:
external/llvm-project/llvm/lib/Support/Unix/Process.inc: In static member function 'static size_t llvm::sys::Process::GetMallocUsage()':
external/llvm-project/llvm/lib/Support/Unix/Process.inc:93:19: error: aggregate 'llvm::sys::Process::GetMallocUsage()::mallinfo mi' has incomplete type and cannot be defined
   93 |   struct mallinfo mi;
      |                   ^~
external/llvm-project/llvm/lib/Support/Unix/Process.inc:94:10: error: '::mallinfo' has not been declared
   94 |   mi = ::mallinfo();
      |          ^~~~~~~~
Target //tensorflow/tools/pip_package:build_pip_package failed to build

Basically mallinfo is not supported on Musl libc, and on upstream LLVM it uses guards to make sure it doesn't get compiled. A combination of CMake checking if the symbol exists, and a guard in the code.

It seems however that Bazel doesn't check that and always sets HAVE_MALLINFO, even if not true?

I made an issue on Tensorflow but got redirected here.

Providing configuration for gollvm

Hi.
I was checking how to build https://go.googlesource.com/gollvm/ with Bazel (CMake free setup).

So I did as described:

$ git clone https://github.com/google/llvm-bazel
$ cd llvm-bazel/third_party
$ rm -Rf llvm-project
$ git clone https://github.com/llvm/llvm-project.git
$ cd llvm-project/llvm/tools
$ git clone https://go.googlesource.com/gollvm
$ cd gollvm
$ git clone https://go.googlesource.com/gofrontend
$ cd libgo
$ git clone https://github.com/libffi/libffi.git
$ git clone https://github.com/ianlancetaylor/libbacktrace.git
$ cd ../../../../../../llvm-bazel
$ bazel build --config=generic_clang @llvm-project//gollvm
Starting local Bazel server and connecting to it...
DEBUG: /home/oceanfish81/.cache/bazel/_bazel_oceanfish81/55a872b9f7a9d080eacfbed36bfc6f31/external/bazel_toolchains/rules/rbe_repo/version_check.bzl:68:14:
Current running Bazel is ahead of bazel-toolchains repo. Please update your pin to bazel-toolchains repo in your WORKSPACE file.
DEBUG: /home/oceanfish81/.cache/bazel/_bazel_oceanfish81/55a872b9f7a9d080eacfbed36bfc6f31/external/bazel_toolchains/rules/rbe_repo/checked_in.bzl:125:14: rbe_default not using checked in configs; Bazel version 4.0.0 was picked/selected but no checked in config was found in map {"0.20.0": ["8.0.0"], "0.21.0": ["8.0.0"], "0.22.0": ["8.0.0", "9.0.0"], "0.23.0": ["8.0.0", "9.0.0"], "0.23.1": ["8.0.0", "9.0.0"], "0.23.2": ["9.0.0"], "0.24.0": ["9.0.0"], "0.24.1": ["9.0.0"], "0.25.0": ["9.0.0"], "0.25.1": ["9.0.0"], "0.25.2": ["9.0.0"], "0.26.0": ["9.0.0"], "0.26.1": ["9.0.0"], "0.27.0": ["9.0.0"], "0.27.1": ["9.0.0"], "0.28.0": ["9.0.0"], "0.28.1": ["9.0.0"], "0.29.0": ["9.0.0"], "0.29.1": ["9.0.0", "10.0.0"], "1.0.0": ["9.0.0", "10.0.0"], "1.0.1": ["10.0.0"], "1.1.0": ["10.0.0"], "1.2.0": ["10.0.0"], "1.2.1": ["10.0.0"], "2.0.0": ["10.0.0"], "2.1.0": ["10.0.0"], "2.1.1": ["10.0.0", "11.0.0"], "2.2.0": ["11.0.0"], "3.0.0": ["11.0.0"], "3.1.0": ["11.0.0"], "3.2.0": ["11.0.0"], "3.3.0": ["11.0.0"], "3.3.1": ["11.0.0"]}
ERROR: Skipping '@llvm-project//gollvm': no such package '@llvm-project//gollvm': BUILD file not found in directory 'gollvm' of external repository @llvm-project. Add a BUILD file to a directory to mark it as a package.
WARNING: Target pattern parsing failed.
ERROR: no such package '@llvm-project//gollvm': BUILD file not found in directory 'gollvm' of external repository @llvm-project. Add a BUILD file to a directory to mark it as a package.
INFO: Elapsed time: 8.653s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded)

So it is super obvious that files like "BUILD" and some others have to be arranged. It is supper annoying to have the sub-directory ../third_party/llvm-project/llvm/tools inside LLVM's root folder (it was more something for CMake's rules, as far as I understood, from the attitude of @thanm, @chrrymui and @ianlancetaylor ).
I was suggesting to have either a sub-folder, which could have a path like ../third_party/llvm-project/gollvm - or move everything into ./llvm_project_overlay/gollvm (interpreting gollvm as a project, which would trigger a required build process of LLVM project - instead of interpreting gollvm as a sub-component).
Eventually this would still be about generating some files, compiling the source files and linking the exec. and shared libs.

Another good option is that it would make sense to consider Bazel's conventions for dealing with dependencies, like libffi and libbacktrace.

I tried the above on Aarch64 server:

$ clang --version
clang version 13.0.0 (https://github.com/llvm/llvm-project.git 5f3c99085d4c2ebf57fd0586b013b02e32a8e20b)
Target: aarch64-unknown-linux-gnu
Thread model: posix

$ lscpu
Architecture: aarch64
CPU op-mode(s): 64-bit
Byte Order: Little Endian
CPU(s): 96
On-line CPU(s) list: 0-95
Thread(s) per core: 1
Core(s) per socket: 48
Socket(s): 2
NUMA node(s): 2
Vendor ID: Cavium
Model: 1
Model name: ThunderX 88XX
Stepping: 0x1
BogoMIPS: 200.00
NUMA node0 CPU(s): 0-47
NUMA node1 CPU(s): 48-95
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Vulnerable
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1: Mitigation; __user pointer sanitization
Vulnerability Spectre v2: Vulnerable
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid

I shall try to reproduce this on x86_64 server.

CC @thanm @ianlancetaylor @cherrymui

hermiticity issue?

$ readelf -p .comment bazel-bin/external/llvm-project/clang/clang

String dump of section '.comment':
  [     1]  GCC: (Debian 10.2.1-6+build2) 10.2.1 20210110
  [    2f]  Nick Desaulniers clang version 13.0.0 ([email protected]:llvm/llvm-project.git 7cd07d339022ef92148e27e8fe12f65865f707d9)

so it seems the .comment section found my local build of clang for parts of the build; it seems this binary is composed of object files built with GCC AND clang. That's unexpected.

Are lit tests handled?

This is a question and not an issue, but I was curious if this build setup handles running LLVM's lit-based tests, and if so, how their build was setup. I searched around and I see the build for the unit tests, but I couldn't find any build for the lit-style tests.

Clang ast unit tests are really slow

The clang ast unit tests take several minutes. Is this necessary? Could we shard them into separate targets?

@llvm-project//clang/unittests:ast_matchers_tests               (cached) PASSED in 171.0s
@llvm-project//clang/unittests:ast_tests                        (cached) PASSED in 166.5s

undefined reference to 'log10'

Apologies if this is a dumb question. I can't quite tell if this is an error on my end or llvm-bazel. Any help appreciated.

When I build @llvm-bazel//... I'm seeing:

bazel-out/host/bin/external/llvm-project/llvm/_objs/Support/Signals.o:Signals.cpp:function printSymbolizedStackTrace(llvm::StringRef, void**, int, llvm::raw_ostream&): error: undefined reference to 'log10'
bazel-out/host/bin/external/llvm-project/llvm/_objs/Support/Signals.o:Signals.cpp:function printSymbolizedStackTrace(llvm::StringRef, void**, int, llvm::raw_ostream&): error: undefined reference to 'log10'

This is when linking mlir/mlir-linalg-ods-yaml-gen but it appears to happen as soon as it attempts to link anything. It seems there might be an -lm missing somewhere.

My configuration is essentially borrowed from xls https://github.com/google/xls/tree/main/dependency_support/llvm_bazel, but I played around with LLVM versions in case that made a difference.

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

def llvm_workspace():
    # newest
    LLVM_COMMIT = "2f69975683f5b6ea7df79f335f96b889a4bddecd"

    # xls
    # LLVM_COMMIT = "628dda08b82fcedcd9e89c9ef7850388e988bf68"  # 2021-04-07
    # LLVM_SHA256 = "b48c8c63c17631cc0160e1359c1e977188aa6cf5924cfd4b5664397effe65f30"
    # LLVM_BAZEL_SHA256 = "259684aa19af62201bd6a261faf315aff8a17dc8bcafcaed372b14108a872f71"

    # llvm-bazel example
    # LLVM_COMMIT = "499bce3abab8a362b9b4197944bd40b826c736c4"
    # LLVM_SHA256 = "a154965dfeb2b5963acc2193bc334ce90b314acbe48430ba310d8a7c7a20de8b"
    # LLVM_BAZEL_SHA256 = "a05a83300b6b4d8b45c9ba48296c06217f3ea27ed06b7e698896b5a3b2ed498d"

    http_archive(
        name = "llvm-bazel",
        # sha256 = LLVM_BAZEL_SHA256,
        strip_prefix = "llvm-bazel-llvm-project-{llvm_commit}/llvm-bazel".format(llvm_commit = LLVM_COMMIT),
        url = "https://github.com/google/llvm-bazel/archive/refs/tags/llvm-project-{llvm_commit}.tar.gz".format(llvm_commit = LLVM_COMMIT),
    )

    http_archive(
        name = "llvm-project-raw",
        build_file_content = "#empty",
        # sha256 = LLVM_SHA256,
        strip_prefix = "llvm-project-" + LLVM_COMMIT,
        url = "https://github.com/llvm/llvm-project/archive/{commit}.tar.gz".format(commit = LLVM_COMMIT),
    )

and

load("@llvm-bazel//:terminfo.bzl", "llvm_terminfo_disable")
load("@llvm-bazel//:zlib.bzl", "llvm_zlib_disable")
load("@llvm-bazel//:configure.bzl", "llvm_configure")

def llvm_initialize():
    llvm_terminfo_disable(
        name = "llvm_terminfo",
    )

    llvm_zlib_disable(
        name = "llvm_zlib",
    )

    # This macro creates a new repo containing the LLVM source code downloaded
    # as llvm-project-raw and the BUILD files from llvm-bazel (contained in the
    # directory llvm-project-overlay). This new repo is constructed as symlinks
    # into these two directories.
    llvm_configure(
        # Name of resulting repo (e.g., "@llvm-project")
        name = "llvm-project",

        # The path to the directory containing the LLVM BUILD files within
        # llvm-bazel.
        overlay_path = "llvm-project-overlay",
        overlay_workspace = "@llvm-bazel//:WORKSPACE",

        # Project containing the llvm source code downloaded with http_archive.
        src_path = ".",
        src_workspace = "@llvm-project-raw//:WORKSPACE",
    )

Really appreciate this effort. Thanks for your help.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.