| Message ID | 20170901074643.rivm2rit53mavkjr@taurus.defre.kleine-koenig.org (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On 2017-09-01 09:46:44, Uwe Kleine-König wrote: > Hello, > > On Thu, Aug 31, 2017 at 11:43:53PM +0100, Ramsay Jones wrote: >> On 31/08/17 21:55, Uwe Kleine-König wrote: >> > On Wed, Aug 30, 2017 at 08:11:49PM -0400, Christopher Li wrote: >> >> That is very much like on x86_64 missing define "#weak_define __x86_64__ 1" >> >> >> >> Does cgcc work for you? In the future we do want to move the archetecture >> >> related define from cgcc into sparse by itself. For now you can set >> >> "sparse" as "cgcc -no-compile" >> > >> > Yes that works. So to address the Debian bug I can do: >> > >> > - move sparse to /usr/lib >> > - teach cgcc about the move of sparse >> > - make /usr/bin/sparse call cgcc -no-compile "$@" >> >> Hmm, I don't think that would be a good idea ... >> >> > or is it easier to teach sparse about the architecture stuff? >> >> I now understand (I think!) that you are building a sparse >> package (presumably a .deb) and you are concerned that sparse >> does not pass it's own testsuite on those platforms. > > Nearly right. I'm responsible for the sparse Debian package and the > problem at hand is https://bugs.debian.org/873508. This bug report has > "Severity: serious" wihch might eventually result in the removal of > sparse from the Debian archive. > > @anarcat: Given that cgcc seems to work, would you agree to apply the > following patch to horst: > > diff --git a/Makefile b/Makefile > index 4f924fa..d563652 100644 > --- a/Makefile > +++ b/Makefile > @@ -110,7 +110,7 @@ $(NAME): $(OBJS) > $(OBJS): .buildflags > > check: > - sparse $(CFLAGS) *.[ch] > + cgcc -no-compile $(CFLAGS) *.[ch] > > clean: > -rm -f *.o radiotap/*.o *~ > > and downgrade the bug to "important"? That would be a compromise that > buys us a bit of time. Well right now I have simply disabled the checks for those broken architectures, so sparse isn't as affected anymore. Frankly, I don't quite know what to do with this - but I'd be happy to happly that patch to sparse if it fixes the issue better. A.
On Fri, Sep 1, 2017 at 3:46 AM, Uwe Kleine-König <uwe@kleine-koenig.org> wrote: \> > Nearly right. I'm responsible for the sparse Debian package and the > problem at hand is https://bugs.debian.org/873508. This bug report has > "Severity: serious" wihch might eventually result in the removal of > sparse from the Debian archive. > > @anarcat: Given that cgcc seems to work, would you agree to apply the > following patch to horst: > > diff --git a/Makefile b/Makefile > index 4f924fa..d563652 100644 > --- a/Makefile > +++ b/Makefile > @@ -110,7 +110,7 @@ $(NAME): $(OBJS) > $(OBJS): .buildflags > > check: > - sparse $(CFLAGS) *.[ch] > + cgcc -no-compile $(CFLAGS) *.[ch] You patch definitely works. I think it is the better way to fix it. Sparse "selfcheck" target was doing the same thing. It is using "cgcc -no-compile" already. I suggest in your patch you can do some thing similar to "selfcheck" target: CHECKER = cgcc -no-compile $(CHECKER) $(CFLAGS) *.[ch] Later when we update sparse to handle architecture properly. We can just invoke make with "CHECKER=xxxx" to test. > and downgrade the bug to "important"? That would be a compromise that > buys us a bit of time. Agree. > > This only solves a part of the problem because the bug report is about > sparse itself, not it's llvm part. I agree with that too. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Control: clone 873508 -1 Control: retitle -1 Please use cgcc to check hosted C code instead of sparse Control: severity -1 normal Control: reassign -1 horst On Fri, Sep 01, 2017 at 09:46:44AM +0200, Uwe Kleine-König wrote: > @anarcat: Given that cgcc seems to work, would you agree to apply the > following patch to horst: > > diff --git a/Makefile b/Makefile > index 4f924fa..d563652 100644 > --- a/Makefile > +++ b/Makefile > @@ -110,7 +110,7 @@ $(NAME): $(OBJS) > $(OBJS): .buildflags > > check: > - sparse $(CFLAGS) *.[ch] > + cgcc -no-compile $(CFLAGS) *.[ch] > > clean: > -rm -f *.o radiotap/*.o *~ > In the meantime I learned from upstream that sparse is not expected to grok arbitrary hosted code. For that it is needed to use the cgcc wrapper to handle the required cpp symbols. That it works on some architectures with plain sparse is mostly luck. I still expect some platforms to fail with the wrapper, too, because cgcc doesn't know about all platforms yet. But I intend to upload a new sparse package soon that includes a build time check for that, and the respective fixes are easy. > and downgrade the bug to "important"? That would be a compromise that > buys us a bit of time. I'd say sparse failing on hosted code isn't "important", but cgcc should have all necessary definitions for Debian platforms. So I'm keeping this bug at important and intend to close it once all platforms are known to it. Best regards Uwe
Control: severity 873508 normal Control: retitle 873508 Fix FTBFS for m68k, hurd, x32 and ppc64 On Thu, Sep 21, 2017 at 08:58:23PM +0200, Uwe Kleine-König wrote: > I still expect some platforms to fail with the wrapper, too, because > cgcc doesn't know about all platforms yet. But I intend to upload a new > sparse package soon that includes a build time check for that, and the > respective fixes are easy. I did that now, and at least all official Debian ports pass that new check. I downgraded the severity accordingly to normal. Current build failures can be seen at https://buildd.debian.org/status/package.php?p=sparse&suite=unstable hurd fails because it doesn't define PATH_MAX and NAME_MAX. m68k fails with sparse: ptrlist.c:125: __add_ptr_list: Assertion `(3 & (unsigned long)ptr) == 0' failed. (Didn't look into this one yet.) And ppc64 and x32 need the respective cpp defines added I think. If noone beats me to it, I will look into the latter at least during the next few days. Best regards Uwe
Control: forwarded -1 https://github.com/br101/horst/issues/93 On 2017-09-01 10:46:44, Uwe Kleine-König wrote: > Hello, > > On Thu, Aug 31, 2017 at 11:43:53PM +0100, Ramsay Jones wrote: >> On 31/08/17 21:55, Uwe Kleine-König wrote: >> > On Wed, Aug 30, 2017 at 08:11:49PM -0400, Christopher Li wrote: >> >> That is very much like on x86_64 missing define "#weak_define __x86_64__ 1" >> >> >> >> Does cgcc work for you? In the future we do want to move the archetecture >> >> related define from cgcc into sparse by itself. For now you can set >> >> "sparse" as "cgcc -no-compile" >> > >> > Yes that works. So to address the Debian bug I can do: >> > >> > - move sparse to /usr/lib >> > - teach cgcc about the move of sparse >> > - make /usr/bin/sparse call cgcc -no-compile "$@" >> >> Hmm, I don't think that would be a good idea ... >> >> > or is it easier to teach sparse about the architecture stuff? >> >> I now understand (I think!) that you are building a sparse >> package (presumably a .deb) and you are concerned that sparse >> does not pass it's own testsuite on those platforms. > > Nearly right. I'm responsible for the sparse Debian package and the > problem at hand is https://bugs.debian.org/873508. This bug report has > "Severity: serious" wihch might eventually result in the removal of > sparse from the Debian archive. > > @anarcat: Given that cgcc seems to work, would you agree to apply the > following patch to horst: > > diff --git a/Makefile b/Makefile > index 4f924fa..d563652 100644 > --- a/Makefile > +++ b/Makefile > @@ -110,7 +110,7 @@ $(NAME): $(OBJS) > $(OBJS): .buildflags > > check: > - sparse $(CFLAGS) *.[ch] > + cgcc -no-compile $(CFLAGS) *.[ch] > > clean: > -rm -f *.o radiotap/*.o *~ > > and downgrade the bug to "important"? That would be a compromise that > buys us a bit of time. For what it's worth, this doesn't work with the latest horst. I've reported the bug upstream now and disabled the checks for all architectures now that it also fails on amd64. A.
On Wed, Jan 09, 2019 at 09:28:54PM -0500, Antoine Beaupré wrote:
> Control: forwarded -1 https://github.com/br101/horst/issues/93
Hi,
The issue showed there, more precisely the one:
/usr/include/x86_64-linux-gnu/bits/mathcalls-helper-functions.h:21:1: error: Expected ) in function declarator
is caused by sparse's lack of support for _Float128 and occurs with
recent version of glibc.
This has been fixed and upstreamed (see
https://git.kernel.org/pub/scm/devel/sparse/sparse.git/commit/?id=4e9c8ee467dd87d41d5aaa3c5a487e3f05ffb79c
for more details).
Best regards,
-- Luc
diff --git a/Makefile b/Makefile index 4f924fa..d563652 100644 --- a/Makefile +++ b/Makefile @@ -110,7 +110,7 @@ $(NAME): $(OBJS) $(OBJS): .buildflags check: - sparse $(CFLAGS) *.[ch] + cgcc -no-compile $(CFLAGS) *.[ch] clean: -rm -f *.o radiotap/*.o *~