Re: emulators/virtualbox-ose-kmod fails to biuld on 14.0-CURRENT 1400079
José Pérez writes: > out/freebsd.amd64/release/bin/src/vboxdrv/freebsd/SUPDrv-freebsd.c:433:50: > error: incompatible pointer to integer conversion passing 'void *' to > parameter of type 'RTR3PTR' (aka 'unsigned long') [-Wint-conversion] > if (RT_FAILURE(RTR0MemUserCopyFrom(&Hdr, pvUser, sizeof(Hdr > ^~ > out/freebsd.amd64/release/bin/src/vboxdrv/freebsd/SUPDrv-freebsd.c:461:50: > error: incompatible pointer to integer conversion passing 'void *' to > parameter of type 'RTR3PTR' (aka 'unsigned long') [-Wint-conversion] > if (RT_FAILURE(RTR0MemUserCopyFrom(pHdr, pvUser, Hdr.cbIn))) > ^~ > out/freebsd.amd64/release/bin/src/vboxdrv/freebsd/SUPDrv-freebsd.c:494:46: > error: incompatible pointer to integer conversion passing 'void *' to > parameter of type 'RTR3PTR' (aka 'unsigned long') [-Wint-conversion] > if (RT_FAILURE(RTR0MemUserCopyTo(pvUser, pHdr, cbOut))) > ^~ > include/iprt/errcore.h:99:58: note: expanded from macro 'RT_FAILURE' > #define RT_FAILURE(rc) ( RT_UNLIKELY(!RT_SUCCESS_NP(rc)) ) > ^~ > include/iprt/errcore.h:80:38: note: expanded from macro 'RT_SUCCESS_NP' > # define RT_SUCCESS_NP(rc) ( (int)(rc) >= VINF_SUCCESS ) > ^~ > include/iprt/cdefs.h:1826:53: note: expanded from macro 'RT_UNLIKELY' > # define RT_UNLIKELY(expr) __builtin_expect(!!(expr), 0) > ^~~~ > include/iprt/mem.h:768:41: note: passing argument to parameter > 'R3PtrDst' here > RTR0DECL(int) RTR0MemUserCopyTo(RTR3PTR R3PtrDst, void const *pvSrc, > size_t cb); > > Is this known? Recent large scale fallout is due to Clang 15 upgrade. Ports with many consumers have been fixed. What's left are ports with few or none consumers, fixing which is left to the respective maintainers or interested users. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265425 https://pkg-status.freebsd.org/builds/default:default:main-amd64:p58633340e9ed_s5636590214:beefy18#new_failed
Re: editors/uemacs fails to biuld on 14.0-CURRENT 1400079
Hi José, On 2023-02-11 08:16:16, José Pérez (f...@aoek.com) wrote: > Hi, > I get the following error when poudriere building editors/uemacs on > 14.0-CURRENT 1400079: > ../src/eval.c:1483:10: error: incompatible pointer to integer conversion > returning 'void *' from a function with result type 'int' [-Wint-conversion] > return NULL; >^~~~ > /usr/include/sys/_null.h:34:14: note: expanded from macro 'NULL' > #define NULL((void *)0) > ^~~ ... > Stop. > make: stopped in /usr/ports/editors/uemacs > > Is this known? The MicroEMACS source code was all written in vintage K&R style. Evidently newer versions of Clang increasingly have a problem with this, which I guess is unsurprising since the minimum C standard Clang is designed for is probably C89/C90. In the K&R days NULL was #defined as 0, so a function returning an int could correctly return NULL. That changed with C89. I'll admit it's a bit strange Clang has decided to clamp down on this some 33 years later. I don't currently have easy access to a FreeBSD machine running clang-15, so can't supply a patch yet, though easiest fix (for now) may be to build uemacs with devel/llvm13 (or maybe devel/llvm14) on FreeBSD 14+. cd /usr/ports/editors/uemacs CC=clang-13 make (untested) Longer term, I'm not sure what the best solution is. I wouldn't expect Clang (or GCC for that matter) to keep supporting uemacs' K&R style C code forever, but converting it all to C90 syntax would be a laborious task. Maybe there are tools for it. Thanks, Andrew
Re: editors/uemacs fails to biuld on 14.0-CURRENT 1400079
On 11/02/23 12:12, andrew clarke wrote: Hi José, On 2023-02-11 08:16:16, José Pérez (f...@aoek.com) wrote: Hi, I get the following error when poudriere building editors/uemacs on 14.0-CURRENT 1400079: ../src/eval.c:1483:10: error: incompatible pointer to integer conversion returning 'void *' from a function with result type 'int' [-Wint-conversion] return NULL; ^~~~ /usr/include/sys/_null.h:34:14: note: expanded from macro 'NULL' #define NULL((void *)0) ^~~ ... Stop. make: stopped in /usr/ports/editors/uemacs Is this known? The MicroEMACS source code was all written in vintage K&R style. Evidently newer versions of Clang increasingly have a problem with this, which I guess is unsurprising since the minimum C standard Clang is designed for is probably C89/C90. In the K&R days NULL was #defined as 0, so a function returning an int could correctly return NULL. That changed with C89. I'll admit it's a bit strange Clang has decided to clamp down on this some 33 years later. I don't currently have easy access to a FreeBSD machine running clang-15, so can't supply a patch yet, though easiest fix (for now) may be to build uemacs with devel/llvm13 (or maybe devel/llvm14) on FreeBSD 14+. cd /usr/ports/editors/uemacs CC=clang-13 make (untested) Longer term, I'm not sure what the best solution is. I wouldn't expect Clang (or GCC for that matter) to keep supporting uemacs' K&R style C code forever, but converting it all to C90 syntax would be a laborious task. Maybe there are tools for it. As far as I understand what happened is that a default was changed, -Wint-conversion is now on by default. So regarding this wouldn't forcing a flag to disable it again be enough? Obviously fixing the code is better whenever possible, but if this code is not fixable due to age, changing flags should be ok. Something like -Wno-error=int-conversion or -Wno-int-conversion should make the error go away. Same with similar issues with this code. I'm not advocating doing this in general. In fact patching the code to not cause these errors should be the solution, but for old code that is not going to change upstream, maybe disabling the warnings is the correct fix. -- Guido Falsi
Re: editors/uemacs fails to biuld on 14.0-CURRENT 1400079
El 2023-02-11 12:45, Guido Falsi escribió:
On 11/02/23 12:12, andrew clarke wrote:
Hi José,
On 2023-02-11 08:16:16, José Pérez (f...@aoek.com) wrote:
Hi,
I get the following error when poudriere building editors/uemacs on
...
The MicroEMACS source code was all written in vintage K&R style.
Evidently
newer versions of Clang increasingly have a problem with this, which I
guess is unsurprising since the minimum C standard Clang is designed
for is
probably C89/C90.
...
Something like -Wno-error=int-conversion or -Wno-int-conversion should
make the error go away. Same with similar issues with this code.
This patch compiles, as a workaround proposed by Guido:
diff --git a/editors/uemacs/Makefile b/editors/uemacs/Makefile
index f999cc978685..48111ffb8824 100644
--- a/editors/uemacs/Makefile
+++ b/editors/uemacs/Makefile
@@ -19,6 +19,8 @@ NO_WRKSUBDIR= yes
USES= dos2unix ncurses zip
EXTRACT_BEFORE_ARGS= -Lq
+CFLAGS+= -Wno-int-conversion
+
post-patch:
@${REINPLACE_CMD} -e "s|%%PREFIX%%|${PREFIX}|g"
${WRKSRC}/src/*.c
@${REINPLACE_CMD} -e 's|-ltermcap|${LDFLAGS} -lncurses|g' \
I'm not advocating doing this in general. In fact patching the code to
not cause these errors should be the solution, but for old code that
is not going to change upstream, maybe disabling the warnings is the
correct fix.
Agreed. For the time being I am using the workaround, will see whether a
consistent patch can be upstreamed.
Regards,
--
José Pérez
Unmaintained FreeBSD ports which are out of date
Dear port maintainers, The portscout new distfile checker has detected that one or more unmaintained ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. Please consider also adopting this port. If any ports have already been updated, you can safely ignore the entry. An e-mail will not be sent again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ cad/ifcopenshell| 0.6.0 | blenderbim-230211 +-+ devel/binaryen | 105 | version_112 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by:portscout!
A pkg-1.19.1 failure doing: pkg delete -a
# pkg delete -a . . . [328/329] Deleting files for bonnie-2.0.6_2: 100% Removing gdk-pixbuf cache directory pkg: sqlite error while executing VACUUM; in file pkgdb.c:2333: cannot VACUUM - SQL statements in progress FYI: # pkg info pkg pkg-1.19.1 Name : pkg Version: 1.19.1 . . . === Mark Millard marklmi at yahoo.com
