HRM, what about biting the bullet and making exec-vary.c a C++ source?... Then instead of making it conditional an attribute((alias)), we make it conditional on having a C++ compiler.
Making cpu-all.h compile as C++ would be complex, but we can isolate all the required declarations in a separate header file that does not need either osdep.h or glib-compat.h, and basically just have a global constructor in exec-vary.cc that forwards to a function in exec.c. Paolo Il dom 21 mar 2021, 18:43 Paolo Bonzini <pbonz...@redhat.com> ha scritto: > > > Il dom 21 mar 2021, 18:34 Richard Henderson <richard.hender...@linaro.org> > ha scritto: > >> On 3/21/21 10:50 AM, Paolo Bonzini wrote: >> > Another workaround may be to avoid compiling exec-vary.c with >> -flto. I'm not >> > sure that my meson fu is up to that. Paolo? >> > >> > You would have to define a static library. >> >> Ok. With an extra -fno-lto flag, or can I somehow remove -flto from the >> library's cflags? Or unset the meson b_lto variable? >> > > -fno-lto should work, yes. b_lto tries to cater to other compilers, but we > don't support anything but gcc-like drivers. > > > I have filed a gcc bug report: >> > >> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99696 >> > >> > Hopefully someone can address that before gcc 11 gets released. At >> which >> > point we need do nothing in qemu. Aldy? >> >> So, I've reproduced the testcase failure with gcc 9.3 (ubuntu 20.04) as >> well. >> Which means that there are at least two releases for which this has not >> worked. >> >> I think Gavin's runtime test is unnecessary. We don't have to check the >> runtime results, we can just [ "$lto" = true ], and we fairly well know >> it'll fail. >> > > Yeah, if anything the test can be used to re-enable attribute((alias)) > once we know there are some fixed compilers. (Though it's quite ugly to > have worse compilation when cross-compiling). > > Paolo > > >> >> r~ >> >>
