Summary: | [patch] comms/linrad : fix two bugs (fatal on gcc5) | ||||||
---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | John Marino <marino> | ||||
Component: | Individual Port(s) | Assignee: | Stephen Hurd <shurd> | ||||
Status: | Closed FIXED | ||||||
Severity: | Affects Only Me | CC: | db, shurd | ||||
Priority: | --- | Keywords: | patch | ||||
Version: | Latest | Flags: | bugzilla:
maintainer-feedback?
(hamradio) |
||||
Hardware: | Any | ||||||
OS: | Any | ||||||
Attachments: |
|
I'll take this, but we haven't had much luck pushing patches upstream with this port. Thanks. If there were any patches that would succeed, it would be these -- unless unstream has no interest in having linrad build on the CURRENT version of gcc. Actually I had marked the port as in progress already and it was in poudriere already. Doesn't matter to me if you want to finish it though. I have had some luck in fixing some of the upstream code in the past. I'll catch you two on IRC. A commit references this bug: Author: db Date: Fri May 1 16:25:52 UTC 2015 New revision: 385126 URL: https://svnweb.freebsd.org/changeset/ports/385126 Log: Fix linrad on latest gcc I checked linrad upstream, and they still haven't fixed these two bugs. I am surprised they haven't been reported yet. Without these fixes, linrad cannot be built with gcc5. the menu.c patch simply reverses the order of the condition. One must check the bounds constraint first! It's a pretty dumb mistake but I've seen this kind before. The second one fails because -Werror is set. This took me a while because I couldn't figure out the relationship between ADCHANS and rxchan. In any case, setting 4 locations per channel did indeed allow the array to be big enough. (at first I thought the loop was running too high, but I finally determined the array was too small). These were found on DragonFly that uses gcc5. This patch has not been tested on FreeBSD but I can't how it could possibly fail. It would be good if the ham@ maintainer reports the issue upstream. Updated patch files using make makepatch PR: ports/199737 Submitted by: marino Changes: head/comms/linrad/Makefile head/comms/linrad/files/patch-Makefile.in head/comms/linrad/files/patch-buf.c head/comms/linrad/files/patch-caliq.c head/comms/linrad/files/patch-configure head/comms/linrad/files/patch-elektor.c head/comms/linrad/files/patch-help.c head/comms/linrad/files/patch-libfind1.c head/comms/linrad/files/patch-libfind2.c head/comms/linrad/files/patch-loadusb.h head/comms/linrad/files/patch-lxsys.c head/comms/linrad/files/patch-menu.c head/comms/linrad/files/patch-users.c head/comms/linrad/files/patch-wse_sdrxx.c head/comms/linrad/pkg-plist |
Created attachment 156048 [details] Fix linrad on latest gcc I checked linrad upstream, and they still haven't fixed these two bugs. I am surprised they haven't been reported yet. Without these fixes, linrad cannot be built with gcc5. the menu.c patch simply reverses the order of the condition. One must check the bounds constraint first! It's a pretty dumb mistake but I've seen this kind before. The second one fails because -Werror is set. This took me a while because I couldn't figure out the relationship between ADCHANS and rxchan. In any case, setting 4 locations per channel did indeed allow the array to be big enough. (at first I thought the loop was running too high, but I finally determined the array was too small). These were found on DragonFly that uses gcc5. This patch has not been tested on FreeBSD but I can't how it could possibly fail. It would be good if the ham@ maintainer reports the issue upstream.