Bug 253303
| Summary: | sysutils/memtest86+: remove dependency on gcc48 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Kyle Evans <kevans> | ||||
| Component: | Individual Port(s) | Assignee: | Kyle Evans <kevans> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Some People | CC: | avg, ports-bugs, rene | ||||
| Priority: | --- | Flags: | kevans:
merge-quarterly+
|
||||
| Version: | Latest | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
Maintainer informed via mail Comment on attachment 222218 [details]
git(1) diff against the ports tree
It looks like bz automation may not like +, tag in avg.
I'll take this as a ports committer, unless avg would prefer to. A-ha, it seems that my local branch was stale; I've locally replaced "USE_GCC= yes" with "USE_GCC= yes:build" to reflect what needs to happen. (In reply to Kyle Evans from comment #3) You are welcome. Thank you! Weird, "maintainer informed by mail" should only occur where the maintainer doesn't have an account in the bugzilla system (because they cant be added to the maintainer-feedback flag field value) Perhaps the + in the summary made it fall through to the same A commit references this bug: Author: kevans Date: Wed Feb 17 01:36:15 UTC 2021 New revision: 565472 URL: https://svnweb.freebsd.org/changeset/ports/565472 Log: sysutils/memtest86+: remove dependency on gcc48 This is one of three ports still explicitly dependent on lang/gcc48. The problems that were preventing the upgrade were as follows: - The __OUT*/__IN* macros in io.h were declaring the produced functions as extern, yielding multiple "definitions." They're inline asm, so just give them static linkage. - reboot was declared inline with non-static linkage, thus leaving it in a weird state where it wasn't visible within the same CU or another CU. Drop the inline for now; if it really needs to be inlined, it can be moved into a header and declared `static inline`. I made these changes, then discovered there's a 5.31b that's still in testing. I checked the archive for that and was delighted to discover these changes had already actually been made there, too, so let's consider this a backport. PR: 253303 Approved by: avg (maintainer) MFH: 2021Q1 Changes: head/sysutils/memtest86+/Makefile head/sysutils/memtest86+/files/patch-io.h head/sysutils/memtest86+/files/patch-lib.c A commit references this bug: Author: kevans Date: Wed Feb 17 01:37:58 UTC 2021 New revision: 565473 URL: https://svnweb.freebsd.org/changeset/ports/565473 Log: MFH: r565472 sysutils/memtest86+: remove dependency on gcc48 This is one of three ports still explicitly dependent on lang/gcc48. The problems that were preventing the upgrade were as follows: - The __OUT*/__IN* macros in io.h were declaring the produced functions as extern, yielding multiple "definitions." They're inline asm, so just give them static linkage. - reboot was declared inline with non-static linkage, thus leaving it in a weird state where it wasn't visible within the same CU or another CU. Drop the inline for now; if it really needs to be inlined, it can be moved into a header and declared `static inline`. I made these changes, then discovered there's a 5.31b that's still in testing. I checked the archive for that and was delighted to discover these changes had already actually been made there, too, so let's consider this a backport. PR: 253303 Approved by: avg (maintainer) Changes: _U branches/2021Q1/ branches/2021Q1/sysutils/memtest86+/Makefile branches/2021Q1/sysutils/memtest86+/files/patch-io.h branches/2021Q1/sysutils/memtest86+/files/patch-lib.c |
Created attachment 222218 [details] git(1) diff against the ports tree This is one of three ports still explicitly dependent on lang/gcc48. The problems that were preventing the upgrade were as follows: - The __OUT*/__IN* macros in io.h were declaring the produced functions as extern, yielding multiple "definitions." They're inline asm, so just give them static linkage. - reboot was declared inline with non-static linkage, thus leaving it in a weird state where it wasn't visible within the same CU or another CU. Drop the inline for now; if it really needs to be inlined, it can be moved into a header and declared `static inline`. I made these changes, then discovered there's a 5.31b that's still in testing. I checked the archive for that and was delighted to discover these changes had already actually been made there, too, so let's consider this a backport.