lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Warnings with gcc-8.2


From: Greg Chicares
Subject: Re: [lmi] Warnings with gcc-8.2
Date: Wed, 20 Mar 2019 15:23:33 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

On 2019-03-20 14:08, Vadim Zeitlin wrote:
> On Wed, 20 Mar 2019 11:28:20 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> However, your source file may very well differ from mine, because I'm
> GC> using a version of wx that's almost a year old:
> GC> 
> GC> /cache_for_lmi/vcs/wxWidgets[0]$git log -1
> GC> commit e38866d3a603f600f87016458260f73593627348 (HEAD)
> [...] I can reproduce the warnings perfectly well with
> tif_predict.c version from the src/tiff submodule commit corresponding to
> this wxWidgets commit. And I see that the warning has indeed been fixed in
> the upstream libtiff sources more than a year ago (but it was merged into
> wx only later)

Okay, this warning will vanish the next time we upgrade wx for lmi.
For now, it's of no relevance, and we'll continue to ignore it.

> GC> Yes, I'll look into that, now that I know MinGW-w64 gcc-8.2 doesn't have
> GC> std::filesystem yet and we'll therefore have to keep boost for a while
> GC> longer.
> 
>  From what I understand, the native builds of the compiler do have it, but
> the Debian build of the cross-compiler somehow doesn't. I am really not
> sure why, but perhaps we could just use the library from the native
> compiler distribution? This looks dirty and I haven't tried it, but if it
> could allow us to finally switch to std::filesystem and drop Boost stuff,
> it might be worth trying, what do you think?

That's an interesting idea, but I'm leery of it. I imagine this isn't an
all-header library, so we can't just copy the source--we'd need to copy
binary files as well. And the MinGW-w64 sf.net site seems to offer only
gcc-8.1.0, whereas debian 'buster' has 8.2.0, so copying binaries from
8.1 into 8.2 might not work. Perhaps debian has excluded std::filesystem
for a good reason.

> GC> Here's the entire command for compiling 'previewframe_ex.o', with all
> GC> of its output:
[...]
> GC> /opt/lmi/local/include/wx-3.1/wx/hashmap.h:510:12: error: but 'size_t 
> wxIntegerHash::operator()(long unsigned int) const' does not throw; perhaps 
> it should be declared 'noexcept' [-Werror=noexcept]
> GC>      size_t operator()( unsigned long x ) const { return ulongHash( x ); }
> GC>             ^~~~~~~~
[...]
>  This one still remains unexplained, however. Using wxWidgets commit
> e38866d3a603f600f87016458260f73593627348 and the same command line with
> just the paths being adjusted, I get many "cast-function-type" warnings and
> one "redundant-decls" warning for wxQsort. And if I disable both of these
> warnings using the corresponding -Wno-xxx options, I don't get any warnings
> any more.
> 
>  I'm really not sure what am I doing wrong. The standard library headers do
> seem to be the same, i.e. the line numbers above correspond to the files on
> my system, and we've already checked that the compiler itself was the same
> one and I'm now testing with the same wxWidgets version. What else could be
> possibly different?

Maybe I should try rebuilding after the equinox, because I can't think of
anything else that can be different.

>  For now I'll look into fixing the "redundant-decls" warning for wxQsort,
> as this one is still present in wx master, and will try to return to the
> "noexcept" one later, in the hope that I have some fresh ideas by then,
> because right now I don't have any...

Neither do I, sorry. We get a clean build with gcc-7.3.0, which presumably
means lmi is noexcept-clean except for these wx hash functions, so it
shouldn't matter very much to inhibit the warning for a while. I imagine
I'll be able to turn it off for wx-dependent code only, for now.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]