I finally managed to upgrade to Fedora 30. I'll try to prepare patches for
this myself.
--
Nadav Har'El
n...@scylladb.com
On Sun, May 19, 2019 at 11:15 AM Nadav Har'El <n...@scylladb.com> wrote:
>
> On Sat, May 18, 2019 at 8:02 PM Waldek Kozaczuk <jwkozac...@gmail.com>
> wrote:
>
>> When building with newest gcc 9 on Fedora 30 one can see following
>> warnings:
>>
>
> Thanks for looking into this. For some weird reason I haven't yet been
> able to upgrade
> my desktop to Fedora 30 (some weird dependency problems), so I can't yet
> check this
> myself. I'll try again soon.
>
>
>>
>> 1)
>> CXX runtime.cc
>> function ‘void {anonymous}::tracepointv<_id, std::tuple<_Elements
>> ...>(r_args ...), assign>::operator()(
>> r_args ...)’:
>> arch/x64/arch-trace.hh:37:66: warning: attribute ignored [-Wattributes]
>> 37 | = [](tracepointv* tp, decltype(data)* d)
>> [[gnu::cold]] {
>> | ^
>> arch/x64/arch-trace.hh:37:66: note: an attribute that appertains to a
>> type-specifier is ignored
>> In file included from include/osv/trace.hh:407,
>> from core/sched.cc:18:
>>
>
> Apparently, the C++ standard requires that these attributes be put only on
> a function's
> declaration, not its definition. Since for a lambda, these two are in the
> same place, gcc
> started complaining.
>
> If we don't want to plainly remove this gnu::cold attribute (I assume it's
> there for a good
> reason, and someone noticed it improves something), one way is to move
> this lamda
> function to a real static function, but the absolute easiest solution is
> to simply replace
> the faux-standard [[gnu::cold]] by the oldstyle equivalent:
> __attribute__((cold))
> That should work (we used this trick in the Seastar project), and I
> recommend that
> we do this here too.
>
>
>> arch/x64/arch-trace.hh: In member function ‘void
>> {anonymous}::tracepointv<_id, std::tuple<_Elements ...>(r_args ...),
>> assign>::operator()(r_args ...)’:
>> arch/x64/arch-trace.hh:37:66: warning: attribute ignored [-Wattributes]
>> 37 | = [](tracepointv* tp, decltype(data)* d)
>> [[gnu::cold]] {
>> | ^
>> arch/x64/arch-trace.hh:37:66: note: an attribute that appertains to a
>> type-specifier is ignored
>> In file included from include/osv/trace.hh:407,
>> from include/osv/mmu.hh:22,
>> from core/mmio.cc:9:
>> arch/x64/arch-trace.hh: In member function ‘void
>> {anonymous}::tracepointv<_id, std::tuple<_Elements ...>(r_args ...),
>> assign>::operator()(r_args ...)’:
>> arch/x64/arch-trace.hh:37:66: warning: attribute ignored [-Wattributes]
>> 37 | = [](tracepointv* tp, decltype(data)* d)
>> [[gnu::cold]] {
>> | ^
>> arch/x64/arch-trace.hh:37:66: note: an attribute that appertains to a
>> type-specifier is ignored
>> In file included from include/osv/trace.hh:407,
>> from core/trace.cc:8:
>>
>>
>> 2)
>> In file included from libc/stdio/stdio_impl.h:5,
>> from libc/stdio/vsscanf.c:1:
>> libc/stdio/vsscanf.c:18:20: warning: ‘__isoc99_vsscanf’ specifies less
>> restrictive attribute than its target ‘vsscanf’: ‘nothrow’
>> [-Wmissing-attributes]
>> 18 | weak_alias(vsscanf,__isoc99_vsscanf);
>> | ^~~~~~~~~~~~~~~~
>> libc/stdio/../internal/libc.h:44:16: note: in definition of macro
>> ‘__weak_alias’
>> 44 | __typeof(old) new __attribute__((weak, alias(#old)))
>> | ^~~
>> libc/stdio/vsscanf.c:18:1: note: in expansion of macro ‘weak_alias’
>> 18 | weak_alias(vsscanf,__isoc99_vsscanf);
>> | ^~~~~~~~~~
>> In file included from libc/stdio/stdio_impl.h:4,
>> from libc/stdio/vsscanf.c:1:
>> include/api/stdio.h:112:5: note: ‘__isoc99_vsscanf’ target declared here
>> 112 | int vsscanf(const char *__restrict, const char *__restrict,
>> va_list);
>> | ^~~~~~~
>>
>>
> I'm not sure what's going on here. My only guess is that __typeof() for a
> C type adds this "nothrow" which
> then confuses the C compiler.
>
> We can perhaps change weak_alias to copy the attributes exactly, e.g.,
> instead of this in libc/internal/libc.h
>
> #define __weak_alias(old, new) \
> __typeof(old) new __attribute__((weak, alias(#old)))
>
> Perhaps this will work (but will it work on older compilers? maybe need
> addition #if's?)
>
> #define __weak_alias(old, new) \
> __typeof(old) new __attribute__((weak, alias(#old)))
> __attribute_copy__(old)
>
> Another possibility is perhaps to change just the C version - from
>
> #define weak_alias(old, new) extern __weak_alias(old, new)
>
> to extern "C" (despite being C!) or explicitly add
> __attribute__((nothrow)) or something in this definition.
>
>
>
>
>>
>> The first one I am not sure how to fix, the second one seems easier,
>>
>> Also at the very end we get an error when running mkfs
>> Running mkfs...
>> /tools/cpiod.so: failed looking up symbol
>> _ZNK5boost15program_options22error_with_option_name4whatEv (bo
>> ost::program_options::error_with_option_name::what() const)
>>
>> [backtrace]
>> 0x000000000035ff26 <elf::object::symbol(unsigned int, bool)+1542>
>> 0x00000000003aaa59 <elf::object::arch_relocate_rela(unsigned int,
>> unsigned int, void*, long)+345>
>> 0x000000000035c6e3 <elf::object::relocate_rela()+195>
>> 0x000000000035d96a <elf::object::relocate()+138>
>> 0x000000000036185c
>> <elf::program::load_object(std::__cxx11::basic_string<char,
>> std::char_traits<char>, s
>> td::allocator<char> >, std::vector<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocat
>> or<char> >, std::allocator<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char>
>> > > >, std::vector<std::shared_ptr<elf::object>,
>> std::allocator<std::shared_ptr<elf::object> > >&)+2380
>> >
>> 0x00000000003627a0
>> <elf::program::get_library(std::__cxx11::basic_string<char,
>> std::char_traits<char>, s
>> td::allocator<char> >, std::vector<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocat
>> or<char> >, std::allocator<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char>
>> > > >, bool)+336>
>> 0x0000000000435b4b
>> <osv::application::application(std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const&,
>> std::vector<std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > > > const&, bool,
>> std::unordered_map<std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> >, std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >,
>> std::hash<std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > >, std::equal_to<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > > > const*, std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const&,
>> std::function<0x0000000000435e5b
>> <osv::application::run(std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const&,
>> std::vector<std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > > > const&, bool,
>> std::unordered_map<std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> >, std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >,
>> std::hash<std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > >, std::equal_to<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > > > const*, std::__cxx11::basic_string<char,
>> std::ch:
>>
>>
>> Looks like the boost incompatibly or something.
>>
>
> Can you please try "make clean" first to make sure we are not combining
> object files from different versions?
> Or maybe we're using some Boost stuff from the build system together with
> things from external/ (we're trying
> to get rid of those....).
>
>
>> native-image with rofs seems to work.
>>
>> Waldek
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "OSv Development" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to osv-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/osv-dev/60282385-f0bc-47dc-9d7f-26b21a66ad55%40googlegroups.com
>> <https://groups.google.com/d/msgid/osv-dev/60282385-f0bc-47dc-9d7f-26b21a66ad55%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
You received this message because you are subscribed to the Google Groups "OSv
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/osv-dev/CANEVyjsdXWo402Oz%3Dp8vOLNLz3KrpEdAQzng7Kc%3Dmb1qkxAwaA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
