[libcxx] [ci] Check that Windows static libraries don't contain dllexports

[ldionne]

libcxx/utils/ci/run-buildbot

146 ↗

(On Diff #413632)

I would like to implement these checks using a test like libcxx/test/libcxx/vendor/apple/system-install-properties.sh.cpp instead. I want to avoid bloating run-buildbot and adding logic to it. Also, we should be performing those checks when we run ninja check-cxx, not only when we run on the CI.

The infrastructure for these kinds of checks is still rather immature, but the idea is that I'd like upstream libc++ to have a place to perform vendor or platform specific checks as part of libc++'s own tests. For example, making sure that the install_name is the right one, that we re-export the right symbols, etc. And this would also extend to check-cxx-abilist -- I have a local patch that tries to move the abilist tests to that infrastructure, but it's not complete enough to publish.

In summary: I'd like to make libcxx/test/libcxx/vendor (we can bikeshed on a different directory name) the canonical place for these kinds of tests.

[mstorsjo]

Converted to a regular test as suggested. Unfortunately, the filename differs between clang-cl and mingw configs, so I duplicated the test (under vendor/mingw and vendor/clangcl) - not sure if there's any better way to have conditionals in this kind of test.

[ldionne]

I really like this direction!

libcxx/test/libcxx/vendor/clangcl/static-lib-exports.sh.cpp

11–12 ↗

(On Diff #416301)

14 ↗

(On Diff #416301)

Is llvm-readobj always available? If not, it would be nice to avoid the creation of a different lit feature for each utility that we need to use. I wonder whether it would be a reasonable requirement to make sure llvm-readobj is built in order to run the libc++ test suite. Maybe not?

libcxx/test/libcxx/vendor/mingw/static-lib-exports.sh.cpp

12–13

[mstorsjo]

libcxx/test/libcxx/vendor/clangcl/static-lib-exports.sh.cpp

11–12 ↗

(On Diff #416301)

MinGW is also Windows, but maybe "in clang-cl builds"?

14 ↗

(On Diff #416301)

Technically I guess it could be possible to not have it, but it's available in the CI environment and it's available in the LLVM installer on Windows, so I don't think we'd have anyone come complaining about running the libcxx tests and having this test failing due to the tool missing.

[mstorsjo]

Clarified the comments roughly as suggested.

libcxx/test/libcxx/vendor/clang-cl/static-lib-exports.sh.cpp

+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+// REQUIRES: msvc
+
+// This file checks that the built static library doesn't contain dllexport
+// directives in clang-cl builds.
+
+// RUN: llvm-readobj --coff-directives "%{lib}/libc++.lib" | not grep -i "export:" > /dev/null
+
+// It's a known issue, that when building a shared library at the same time
+// as the static library, the generated static library does contain dllexport
+// directives.
+// XFAIL: windows-dll

libcxx/test/libcxx/vendor/mingw/static-lib-exports.sh.cpp

+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+// REQUIRES: target={{.+}}-windows-gnu
+
+// This file checks that the built static library doesn't contain dllexport
+// directives in MinGW builds.
+
+// RUN: llvm-readobj --coff-directives "%{lib}/libc++.a" | not grep -i "export:" > /dev/null
+
+// It's a known issue, that when building a shared library at the same time
+// as the static library, the generated static library does contain dllexport
+// directives.
+// XFAIL: windows-dll