[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)

via llvm-branch-commits llvm-branch-commits at lists.llvm.org
Mon Dec 16 17:05:54 PST 2024


h-vetinari wrote:

> @h-vetinari Is this using a bootstrap or default-only build? Is flang built in-tree or out-of-tree? Is `flang` in the build- or install-tree? Did you check whether the `flang_rt.static.lib` is present?
> 
> I am going to test more configurations under Windows trying to reproduce this. Narrowing it down would help.

On a basis of already-compiled & installed `llvm` (the subproject), clang, mlir, compiler-rt, we first build flang, and then flang-rt using the just-built flang. Both get installed (ultimately) into the same install tree where the other LLVM bits are already present*, so in the end it should be pretty standard -- all in one place. I did check that `flang_rt.static.lib` is present (under the path I described, i.e. `/lib/windows/flang_rt.static.lib`, relative to `CMAKE_INSTALL_PREFIX`).

<details>
<summary>* details</summary>
 
this is actually the mechanism that defines what the "installation" of a given package X means from the POV of conda-build; i.e. populate the the install-tree with whatever needs to be there, take a snapshot before and after installation, then the (positive) delta between the before/after snapshots defines the content of X _as installed_.

For testing, there's a further level of isolation from the build environment, in that everything gets torn down and then recreated based on what has been determined to be the package content (plus all specified dependencies), and _then_ run the tests. This is to avoid spuriously relying on stuff from the build tree, and forcing the installation to be explicit about what it needs to put into the installation-`$PREFIX`. It also ends up testing/enforcing relocatability (which needs some more magic on linux, but it's possible).

</details>

In sequence, we do:
* set up install-tree with the (LLVM) bits required to build flang
* build [flang](https://github.com/h-vetinari/flang-feedstock/blob/dev/recipe/bld.bat)
* build [flang-rt](https://github.com/h-vetinari/flang-feedstock/blob/dev/recipe/install_flang-rt.bat)
* [build some wrappers that just add metadata]
* run tests

Everything is held together by a [recipe](https://github.com/h-vetinari/flang-feedstock/blob/dev/recipe/meta.yaml), but I don't expect that to be immediately self-evident (happy to explain what's happening though!).

So for the final test, we create an environment that looks like
```
TEST START: C:\bld\win-64\flang_win-64-20.0.0.dev3-h0d486fc_0.conda
[...]

## Package Plan ##

  environment location: C:\bld\flang-split_1734298984217\_test_env


The following NEW packages will be INSTALLED:

    clang:              20.0.0.dev3-default_h00e4eaa_0 conda-forge/label/llvm_dev
    clang-20:           20.0.0.dev3-default_h00e4eaa_0 conda-forge/label/llvm_dev
    compiler-rt:        20.0.0.dev3-h85af4db_0         conda-forge/label/llvm_dev
    compiler-rt_win-64: 20.0.0.dev3-h85af4db_0         conda-forge/label/llvm_dev
    flang:              20.0.0.dev3-hb33b443_0         local                     
    flang-rt:           20.0.0.dev3-h963887e_0         local                     
    flang_impl_win-64:  20.0.0.dev3-h0d486fc_0         local                     
    flang_win-64:       20.0.0.dev3-h0d486fc_0         local                     
    libiconv:           1.17-hcfcfb64_2                conda-forge               
    libllvm20:          20.0.0.dev3-h7de1732_0         conda-forge/label/llvm_dev
    libxml2:            2.13.5-he286e8c_1              conda-forge               
    libzlib:            1.3.1-h2466b09_2               conda-forge               
    lld:                20.0.0.dev3-h4ef2093_0         conda-forge/label/llvm_dev
    llvm-tools:         20.0.0.dev3-h6f9bbfe_0         conda-forge/label/llvm_dev
    ucrt:               10.0.22621.0-h57928b3_1        conda-forge               
    vc:                 14.3-ha32ba9b_23               conda-forge               
    vc14_runtime:       14.42.34433-he29a5d6_23        conda-forge               
    zstd:               1.5.6-h0ea2cb4_0               conda-forge 
```
The `local` packages are the ones that have just been built (not yet published); the ones from the `llvm_dev` label have been built & published previously (but from the same commit). `flang{,_impl}_win-64` are the metapackages I mentioned that don't change anything.

The testing order follows the DAG of dependencies, IOW, since `flang_win-64` (the final compiler) depends on `flang-rt`, the tests for `flang-rt` have already run before, and I've explicitly [tested](https://github.com/h-vetinari/flang-feedstock/blob/e86a0e2a0ab30056f6d924dcd4668ec975328767/recipe/meta.yaml#L60) the presence of `flang_rt.static.lib` _as installed_. In particular, this guarantees that this library is in the expected location when we end up testing `flang_win-64`.

Here are the full [logs](https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=1110855&view=results) if you're interested (note that azure pipelines deletes the logs after a month).

https://github.com/llvm/llvm-project/pull/110217


More information about the llvm-branch-commits mailing list