Hey all,
Recently, one of the folks working on packaging stuff in Fedora KDE nearly missed an issue caused by GCC emitting a warning about missing include dirs:
cc1plus: warning: /usr/include/qt6/QtCore/6.5.3: No such file or directory [-Wmissing-include-dirs] cc1plus: warning: /usr/include/qt6/QtCore/6.5.3/QtCore: No such file or directory [-Wmissing-include-dirs]
I did manage to figure out this meant we needed an additional build dependency (qt6-qtbase-private-devel, FYI), but it made me think if there's a reason this shouldn't be an error.
If it's an error, then at least we can evaluate these things and ensure we have the right build inputs...
What do y'all think?
* Neal Gompa:
Hey all,
Recently, one of the folks working on packaging stuff in Fedora KDE nearly missed an issue caused by GCC emitting a warning about missing include dirs:
cc1plus: warning: /usr/include/qt6/QtCore/6.5.3: No such file or directory [-Wmissing-include-dirs] cc1plus: warning: /usr/include/qt6/QtCore/6.5.3/QtCore: No such file or directory [-Wmissing-include-dirs]
I did manage to figure out this meant we needed an additional build dependency (qt6-qtbase-private-devel, FYI), but it made me think if there's a reason this shouldn't be an error.
Was there a subsequent build failure due to the missing headers? Could you share a link to the full build log?
Thanks, Florian
On Tue, Oct 10, 2023 at 11:59 AM Neal Gompa ngompa13@gmail.com wrote:
Hey all,
Recently, one of the folks working on packaging stuff in Fedora KDE nearly missed an issue caused by GCC emitting a warning about missing include dirs:
cc1plus: warning: /usr/include/qt6/QtCore/6.5.3: No such file or
directory [-Wmissing-include-dirs]
cc1plus: warning: /usr/include/qt6/QtCore/6.5.3/QtCore: No such file or
directory [-Wmissing-include-dirs]
I did manage to figure out this meant we needed an additional build dependency (qt6-qtbase-private-devel, FYI), but it made me think if there's a reason this shouldn't be an error.
If it's an error, then at least we can evaluate these things and ensure we have the right build inputs...
Missing an include directory isn't necessarily the problem though, it is the missing headers that aren't present when they are included that would be - and that should trigger a build error for the missing file. What advantage does failing on this warning provide that the failure on the include file missing doesn't?
-Ian
What do y'all think?
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Tue, 10 Oct 2023 at 12:17, Ian McInerney via devel devel@lists.fedoraproject.org wrote:
On Tue, Oct 10, 2023 at 11:59 AM Neal Gompa ngompa13@gmail.com wrote:
Hey all,
Recently, one of the folks working on packaging stuff in Fedora KDE nearly missed an issue caused by GCC emitting a warning about missing include dirs:
cc1plus: warning: /usr/include/qt6/QtCore/6.5.3: No such file or directory [-Wmissing-include-dirs] cc1plus: warning: /usr/include/qt6/QtCore/6.5.3/QtCore: No such file or directory [-Wmissing-include-dirs]
I did manage to figure out this meant we needed an additional build dependency (qt6-qtbase-private-devel, FYI), but it made me think if there's a reason this shouldn't be an error.
If it's an error, then at least we can evaluate these things and ensure we have the right build inputs...
Missing an include directory isn't necessarily the problem though, it is the missing headers that aren't present when they are included that would be - and that should trigger a build error for the missing file. What advantage does failing on this warning provide that the failure on the include file missing doesn't?
Typically, yes, I'd expect a failure. But it's possible for code to do:
#if __has_include(<foo.h>) # include <foo.h> // use features in that header #else // roll your own inferior version #endif
And so the code could compile either way, but with results that differ depending on whether <foo.h> is found or not. The extra -I include dir could be given to the compiler so that if <foo.h> is present in that dir, it will be found and used. If it's not present, there's no harm. I don't expect this to be a very widely used pattern though.
The above doesn't necessarily argue for or against making it an error. There are arguments either way. Making it an error might give some maintainers a heads up that something's missing, but for other packages it would break a valid use case.
On Mon, Nov 13, 2023 at 5:16 PM Jonathan Wakely jwakely@redhat.com wrote:
Typically, yes, I'd expect a failure. But it's possible for code to do:
#if __has_include(<foo.h>) # include <foo.h> // use features in that header #else // roll your own inferior version #endif
And in the particular case of the Qt private headers (where this started) I have seen this, or an equivalent construct, used to not support a feature at all.
And yes, I do believe Qt places some things into private headers that they should probably provide a public API to access, but that is a different issue.
In *theory* the application would report that feature X is disabled or unavailable during configuration and/or during the checks, and the packager would be expected to realize the implications, but for large apps such messages might be missed or not understood.
I am slightly in favor of making missing headers an error as long as it is easy enough to override that to at least provide a few more guard rails.
* Jonathan Wakely:
Missing an include directory isn't necessarily the problem though, it is the missing headers that aren't present when they are included that would be - and that should trigger a build error for the missing file. What advantage does failing on this warning provide that the failure on the include file missing doesn't?
Typically, yes, I'd expect a failure. But it's possible for code to do:
#if __has_include(<foo.h>) # include <foo.h> // use features in that header #else // roll your own inferior version #endif
I can see this might be a problem.
I wouldn't object if someone submitted a change proposal for this, but they have to do the necessary work (full distribution rebuild to assess the impact of the change, preferably with an instrumented/wrapped toolchain to catch silently miscompiled autoconf probes).
Thanks, Florian
On Tue, Oct 10, 2023 at 12:16:55PM +0100, Ian McInerney via devel wrote:
On Tue, Oct 10, 2023 at 11:59 AM Neal Gompa ngompa13@gmail.com wrote:
Hey all,
Recently, one of the folks working on packaging stuff in Fedora KDE nearly missed an issue caused by GCC emitting a warning about missing include dirs:
cc1plus: warning: /usr/include/qt6/QtCore/6.5.3: No such file or
directory [-Wmissing-include-dirs]
cc1plus: warning: /usr/include/qt6/QtCore/6.5.3/QtCore: No such file or
directory [-Wmissing-include-dirs]
I did manage to figure out this meant we needed an additional build dependency (qt6-qtbase-private-devel, FYI), but it made me think if there's a reason this shouldn't be an error.
If it's an error, then at least we can evaluate these things and ensure we have the right build inputs...
Missing an include directory isn't necessarily the problem though, it is the missing headers that aren't present when they are included that would be - and that should trigger a build error for the missing file. What advantage does failing on this warning provide that the failure on the include file missing doesn't?
The header file may be present in another directory, but as an older version that should not be used, resulting in building the wrong featureset.
Last week I uncovered a bug in opensuse 15.4 where they had patched libtirpc to move its headers directly into /usr/include, but not correctly changed the pkg-config file which still pointed to the non-existant /usr/include/libtirpc.
This case was harmless, as /usr/include is on the default search path, but it was none the less a genuine bug, and was caught due our code using -Werror=missing-include-dirs in CI.
The reason for missing-include-dirs to not to be a build error by default though, is that I suspect there are plenty of apps which have sloppy build system setup that results in bogus dirs being added.
With regards, Daniel
On Tue, Oct 10, 2023 at 06:57:40AM -0400, Neal Gompa wrote:
Hey all,
Recently, one of the folks working on packaging stuff in Fedora KDE nearly missed an issue caused by GCC emitting a warning about missing include dirs:
cc1plus: warning: /usr/include/qt6/QtCore/6.5.3: No such file or directory [-Wmissing-include-dirs] cc1plus: warning: /usr/include/qt6/QtCore/6.5.3/QtCore: No such file or directory [-Wmissing-include-dirs]
I did manage to figure out this meant we needed an additional build dependency (qt6-qtbase-private-devel, FYI), but it made me think if there's a reason this shouldn't be an error.
If it's an error, then at least we can evaluate these things and ensure we have the right build inputs...
What do y'all think?
I might be missing the point, but what issue did this cause?
Rich.
On Tue, Oct 10, 2023 at 11:01 AM Richard W.M. Jones rjones@redhat.com wrote:
On Tue, Oct 10, 2023 at 06:57:40AM -0400, Neal Gompa wrote:
Hey all,
Recently, one of the folks working on packaging stuff in Fedora KDE nearly missed an issue caused by GCC emitting a warning about missing include dirs:
cc1plus: warning: /usr/include/qt6/QtCore/6.5.3: No such file or directory [-Wmissing-include-dirs] cc1plus: warning: /usr/include/qt6/QtCore/6.5.3/QtCore: No such file or directory [-Wmissing-include-dirs]
I did manage to figure out this meant we needed an additional build dependency (qt6-qtbase-private-devel, FYI), but it made me think if there's a reason this shouldn't be an error.
If it's an error, then at least we can evaluate these things and ensure we have the right build inputs...
What do y'all think?
I might be missing the point, but what issue did this cause?
I don't know if it did or didn't. For all I know, it could have led to a miscompilation. It was fixed before we landed it as it was caught while working on packaging.
-
Daniel P. Berrangé -
Florian Weimer -
Gary Buhrmaster -
Ian McInerney -
Jonathan Wakely -
Neal Gompa -
Richard W.M. Jones