This is an archive of the discontinued LLVM Phabricator instance.

[runtimes] Always define the cxx_shared, cxx_static & other targets
AcceptedPublic

Authored by ldionne on Sep 19 2022, 1:26 PM.

Details

Reviewers
daltenty
Group Reviewers
Restricted Project
Restricted Project
Restricted Project
Commits
rG79ee0342dbf0: [runtimes] Always define cxx_shared, cxx_static & other targets
Summary

However, mark them as EXCLUDE_FROM_ALL when we don't want to build them.
Simply declaring the targets should be of no harm, and it allows other
projects to mention these targets regardless of whether they end up
being built or not.

While the diff may not make that obvious, this patch basically
moves the definition of e.g. cxx_shared out of the if (LIBCXX_ENABLE_SHARED)
and instead marks it as EXCLUDE_FROM_ALL conditionally on whether
LIBCXX_ENABLE_SHARED is passed. It then does the same for libunwind
and libc++abi targets.

Diff Detail

Event Timeline

ldionne created this revision.Sep 19 2022, 1:26 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptSep 19 2022, 1:26 PM
Herald added a reviewer: Restricted Project. · View Herald Transcript
ldionne requested review of this revision.Sep 19 2022, 1:26 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptSep 19 2022, 1:26 PM
Herald added a reviewer: Restricted Project. · View Herald Transcript
Herald added a reviewer: Restricted Project. · View Herald Transcript

@daltenty I looked at the error in https://buildkite.com/llvm-project/libcxx-ci/builds/13649#01835770-a937-4a78-a82e-1dbe3add4e72 but I don't understand why there's a duplicate target producing libunwind.a. Could you please have a quick look? It doesn't reproduce when I use the AIX configuration locally on my mac.

ldionne updated this revision to Diff 464980.Oct 4 2022, 5:49 AM

Rebase onto main.

@daltenty I looked at the error in https://buildkite.com/llvm-project/libcxx-ci/builds/13649#01835770-a937-4a78-a82e-1dbe3add4e72 but I don't understand why there's a duplicate target producing libunwind.a. Could you please have a quick look? It doesn't reproduce when I use the AIX configuration locally on my mac.

Ah, you've stumbled on some particular interestingness of CMake when it comes to AIX. AIX usually archives both shared libraries and static ones (one can actually mix the two in strange and interesting ways). Some versions of CMake on AIX implement this, so both the static and shared targets actually seem to come out with the same output names. We noticed this before but it worked ok for us in practice because we would configure for one or the other but not both.

Not sure what the best resolution is. Perhaps the easiest thing would be to modify the output names for the static libraries when on AIX to avoid the conflict? (though not sure how that effects test config and other usages)

@daltenty I looked at the error in https://buildkite.com/llvm-project/libcxx-ci/builds/13649#01835770-a937-4a78-a82e-1dbe3add4e72 but I don't understand why there's a duplicate target producing libunwind.a. Could you please have a quick look? It doesn't reproduce when I use the AIX configuration locally on my mac.

Ah, you've stumbled on some particular interestingness of CMake when it comes to AIX. AIX usually archives both shared libraries and static ones (one can actually mix the two in strange and interesting ways). Some versions of CMake on AIX implement this, so both the static and shared targets actually seem to come out with the same output names. We noticed this before but it worked ok for us in practice because we would configure for one or the other but not both.

Do you mean that both unwind_shared and unwind_static both create a target named libunwind.a? Is there documentation for that CMake feature? I guess we could change the OUTPUT_NAME of the library, but that seems like kind of a hack.

Do you mean that both unwind_shared and unwind_static both create a target named libunwind.a?

Yes, that's correct.

Is there documentation for that CMake feature?

Very regrettably, this is not a documented feature yet (though it's tracked by issue https://gitlab.kitware.com/cmake/cmake/-/issues/19494). The behaviour exists only in AIX packaged versions of CMake to my knowledge (though work is underway to upstream it).

I guess we could change the OUTPUT_NAME of the library, but that seems like kind of a hack.

Yes, I agree it is quite hackish. The AIX build is pretty reliant on being able to exclude the targets from the build at the moment though unfortunately, so if that is going away I'm afraid some sort of hackery will be required.

Yes, I agree it is quite hackish. The AIX build is pretty reliant on being able to exclude the targets from the build at the moment though unfortunately, so if that is going away I'm afraid some sort of hackery will be required.

Since we already support setting the OUTPUT_NAME of libc++.dylib, I went ahead with that solution in D135669. That way, the output name can be customized in AIX's CMake cache with a comment explaining why that's required.

Note that more generally speaking, I would expect this to cause a lot of issues on AIX with existing CMake projects (libc++/libunwind isn't special in any way here). IMO CMake may want to handle this problem somehow, but I'm not sure how.

ldionne updated this revision to Diff 466888.Oct 11 2022, 12:23 PM

Rebase and address AIX issues.

@daltenty I already had this update ready to go before you created D135699, but let me know if you'd
rather go with yours instead, which is in a separate patch. I have no preference but I did find that
my comment explaining the issue was a bit more detailed.

daltenty accepted this revision.Oct 11 2022, 2:00 PM

Rebase and address AIX issues.

@daltenty I already had this update ready to go before you created D135699, but let me know if you'd
rather go with yours instead, which is in a separate patch. I have no preference but I did find that
my comment explaining the issue was a bit more detailed.

LGTM, thanks! I agree, let's go with this (I can adjust D135699 to include just adding the building of the static libraries)

ldionne accepted this revision as: Restricted Project, Restricted Project, Restricted Project.Oct 12 2022, 6:35 AM

Rebase and address AIX issues.

@daltenty I already had this update ready to go before you created D135699, but let me know if you'd
rather go with yours instead, which is in a separate patch. I have no preference but I did find that
my comment explaining the issue was a bit more detailed.

LGTM, thanks! I agree, let's go with this (I can adjust D135699 to include just adding the building of the static libraries)

Do you actually have to build static libraries? IMO it's fine to just set their name to avoid conflicts but not necessarily build them if you don't need them.

This revision is now accepted and ready to land.Oct 12 2022, 6:35 AM
This revision was landed with ongoing or failed builds.Oct 12 2022, 6:36 AM
This revision was automatically updated to reflect the committed changes.
phosek added a subscriber: phosek.Oct 12 2022, 9:42 AM

All Fuchsia builders started failing after this change landed with the following error:

/b/s/w/ir/x/w/staging/llvm_build/./bin/clang++ --target=x86_64-unknown-fuchsia --sysroot=/b/s/w/ir/x/w/cipd/sdk/arch/x64/sysroot -fPIC --target=x86_64-unknown-fuchsia -I/b/s/w/ir/x/w/cipd/sdk/pkg/sync/include -I/b/s/w/ir/x/w/cipd/sdk/pkg/fdio/include -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -ffunction-sections -fdata-sections  -O3 -DNDEBUG  -L/b/s/w/ir/x/w/cipd/sdk/arch/x64/lib -Wl,-z,defs  -nostdlib++ -shared -Wl,-soname,libc++abi.so.1 -o lib/libc++abi.so.1.0 libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_aux_runtime.cpp.obj libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_default_handlers.cpp.obj libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_demangle.cpp.obj libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_exception_storage.cpp.obj libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_guard.cpp.obj libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_handlers.cpp.obj libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_vector.cpp.obj libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_virtual.cpp.obj libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/stdlib_exception.cpp.obj libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/stdlib_stdexcept.cpp.obj libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/stdlib_typeinfo.cpp.obj libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/abort_message.cpp.obj libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/fallback_malloc.cpp.obj libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/private_typeinfo.cpp.obj libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/stdlib_new_delete.cpp.obj libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_noexception.cpp.obj libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_thread_atexit.cpp.obj  -lc  -lgcc  -lgcc_s && :
ld.lld: error: unable to find library -lgcc
ld.lld: error: unable to find library -lgcc_s

There's no libgcc on Fuchsia, we always use compiler-rt builtins so it's not clear to me why the build is now trying link libgcc when targeting Fuchsia after this change.

Would it be possible to revert this change while we investigate the issue?

pcc added a subscriber: pcc.Oct 12 2022, 12:26 PM

TSan builds are also broken with this change: https://lab.llvm.org/buildbot/#/builders/70/builds/28491

ld: error: undefined symbol: __tsan_func_entry
>>> referenced by cxa_aux_runtime.cpp
>>>               libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_aux_runtime.cpp.o:(__cxa_bad_cast)
>>> referenced by cxa_aux_runtime.cpp
>>>               libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_aux_runtime.cpp.o:(__cxa_bad_typeid)
>>> referenced by cxa_aux_runtime.cpp
>>>               libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_aux_runtime.cpp.o:(__cxa_throw_bad_array_new_length)
>>> referenced 539 more times

(and more undefined symbols).

haowei added a subscriber: haowei.Oct 12 2022, 12:57 PM

I reverted this change in a3539090884c9159893c0b2b4c1dc34f23510707. Both Fuchsia bots and LLVM TSan bots failures indicates there is a regression caused by this change and need further investigation.

ldionne reopened this revision.Oct 12 2022, 3:04 PM

@pcc @phosek

Can you please provide your respective minimal CMake invocations that reproduce that issue? I'll take a look.

This revision is now accepted and ready to land.Oct 12 2022, 3:04 PM
pcc added a comment.Oct 12 2022, 4:00 PM

The sanitizer bot uses a 2-stage build so I'm not sure that it can be reproduced with a single CMake invocation. You should be able to reproduce on Linux with:

git clone https://github.com/llvm/llvm-zorg.git
BUILDBOT_CLOBBER= BUILDBOT_REVISION=79ee0342dbf025bc70f237bdfe9ccb4e10a592ce llvm-zorg/zorg/buildbot/builders/sanitizers/buildbot_standard.sh

@pcc @phosek

Can you please provide your respective minimal CMake invocations that reproduce that issue? I'll take a look.

To setup Fuchsia's clang build you have to download some prebuilt including Fuchsia SDK, clang and sysroot. So it is not a straight forward 1 cmake invocation.
The builder task link is https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8800503429662215329/overview and cmake command can be seen from step https://logs.chromium.org/logs/fuchsia/buildbucket/cr-buildbucket/8800503429662215329/+/u/clang/configure/execution_details