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

subobject-linkage error with GCC #1143

Open
williamspatrick opened this issue Nov 15, 2023 · 3 comments
Open

subobject-linkage error with GCC #1143

williamspatrick opened this issue Nov 15, 2023 · 3 comments

Comments

@williamspatrick
Copy link
Contributor

This could very well be something wrong with my code. Using the latest stdexec, I'm started seeing this subobject-linkage warning in GCC. It isn't obvious which type is even being called out as a problem.

../include/sdbusplus/async/timer.hpp:109:5: error: ‘sdbusplus::async::timer_ns::sleep_sender::sleep_for(sdbusplus::async::context&, sdbusplus::event::event::time_resolution)::_ZN9sdbusplus5async8timer_ns12sleep_sender9sleep_forERNS0_7contextENSt6chrono8durationIlSt5ratioILl1ELl1000000EEEE.Frame’ has a field ‘stdexec::__as_awaitable::__sender_awaitable<stdexec::_Yp<exec::__task::basic_task<void, exec::__task::__default_task_context_impl<exec::__task::__scheduler_affinity::__sticky> >::__promise>, stdexec::__sexpr<stdexec::__detail::{anonymous}::<lambda(_Tag, _Captures&& ...)>::<lambda(_Cvref, _Fun&&)> > >::__t sdbusplus::async::timer_ns::sleep_sender::sleep_for(sdbusplus::async::context&, sdbusplus::event::event::time_resolution)::_ZN9sdbusplus5async8timer_ns12sleep_sender9sleep_forERNS0_7contextENSt6chrono8durationIlSt5ratioILl1ELl1000000EEEE.Frame::Aw1_2_4’ whose type has internal linkage [-Werror=subobject-linkage]

The affected code is a rather simple co-routine using the stdexec task.

    static task<> sleep_for(context& ctx, event_t::time_resolution time)
    {
        // Run the delay sender and then switch back to the worker thread.
        // The delay completion happens from the sd-event handler, which is
        // ran on the 'caller' thread.
        co_await sleep_sender(ctx, time);
        co_await execution::schedule(get_scheduler(ctx));
    }

Both co_awaits have this subobject-linkage problem, so even if I comment out the first one I still end up with it.

@ericniebler
Copy link
Collaborator

ericniebler commented Nov 23, 2023

I think this is https://stackoverflow.com/questions/55881676/werror-subobject-linkage-for-lambda-as-a-template-parameter-in-header-what-i.

It's unclear to me if this is a gcc bug, or if I'm legitimately doing something wrong by using anonymous types / lambdas as template parameters. I don't think there is much I can do about it, though.

If I'm not mistaken, -Wsubobject-linkage is a warning. You're probably seeing it as an error because you are also specifying -Werror, is that right? If so, would you be willing to exclude this warning?

UPDATE: possibly relevant: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111423

@williamspatrick
Copy link
Contributor Author

Thanks for investigating, @ericniebler

I managed to work around it by changing from co_awaits/tasks to senders here. So it isn't pressing right now.

    static auto sleep_for(context& ctx, event_t::time_resolution time)
    {
        // Run the delay sender and then switch back to the worker thread.
        // The delay completion happens from the sd-event handler, which is
        // ran on the 'caller' thread.
        return execution::transfer(sleep_sender(ctx, time), get_scheduler(ctx));
    }

I'm surprised I'm not currently seeing this in any other code using tasks though.

You're probably seeing it as an error because you are also specifying -Werror, is that right? If so, would you be willing to exclude this warning?

Correct. I'm writing a library though so I can't totally control what consumers end up compiling/linking with. Most of the projects in our organization use Meson's warning_level=3 which turns on quite a bit of warnings. In some cases I've pragma'd out some warnings from stdexec, but since this ends up being a linker warning I'm not sure that helps in this case.

@Yaraslaut
Copy link

Let me add some info here since this is one of the first relevant links while searching for this bug.

code like template<typename T = decltype([] {})> is legitimate and part of C++20 standard see cppreference and paper

This is a gcc bug and has been fixed in gcc 14 bugzilla. While this is indeed generates a warning, compilers produce the wrong linkage type for these types and thus failing during linkage, while clang works correctly and gcc will be released at some point, this bug appears to be present in msvc.

P.S. @ericniebler you have extra / in the bugzilla link

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

No branches or pull requests

3 participants