| ^~~~~~~~~~~~~~~~~~~~~~~~~~~ x86_64-pc-linux-gnu-gcc -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0 cut.o -L../libcommon -lcommon -o cut make[1]: Leaving directory '/var/tmp/portage/sys-apps/heirloom-tools-070715-r6/work/heirloom-070715/cut' make[1]: Entering directory '/var/tmp/portage/sys-apps/heirloom-tools-070715-r6/work/heirloom-070715/date' x86_64-pc-linux-gnu-gcc -O3 -pipe -march=native -fno-diagnostics-color -D_GNU_SOURCE -I../libcommon -c date.c date.c: In function settime: date.c:153:22: error: passing argument 1 of gettimeofday from incompatible pointer type [-Wincompatible-pointer-types] 153 | gettimeofday(&before.ut_tv, NULL); | ^~~~~~~~~~~~~ ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_desktop_gnome_systemd-20231123-170505 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-10 [2] x86_64-pc-linux-gnu-14 * clang/llvm (if any): clang version 17.0.6 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/17/bin Configuration file: /etc/clang/x86_64-pc-linux-gnu-clang.cfg /usr/lib/llvm/17 17.0.6 Python 3.11.7 Available Ruby profiles: [1] ruby31 (with Rubygems) * Available Rust versions: [1] rust-bin-1.74.1 * The following VMs are available for generation-2: 1) Eclipse Temurin JDK 11.0.20.1_p1 [openjdk-bin-11] 2) Eclipse Temurin JDK 17.0.8.1_p1 [openjdk-bin-17] *) Eclipse Temurin JDK 21.0.1_p12 [openjdk-bin-21] 4) Eclipse Temurin JDK 8.382_p05 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-bin-8 [2] openjdk-bin-11 [3] openjdk-bin-17 [4] openjdk-bin-21 system-vm The Glorious Glasgow Haskell Compilation System, version 9.2.8 php cli (if any): go version go1.21.4 linux/amd64 HEAD of ::gentoo commit 2f2f8b1061a0f0c1b03783807db60e8e69f3abf9 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Fri Dec 8 12:51:51 2023 +0000 2023-12-08 12:51:50 UTC emerge -qpvO sys-apps/heirloom-tools [ebuild N ] sys-apps/heirloom-tools-070715-r6
Created attachment 878309 [details] emerge-info.txt
Created attachment 878310 [details] emerge-history.txt.xz
Created attachment 878311 [details] environment
Created attachment 878312 [details] etc.clang.tar.xz
Created attachment 878313 [details] etc.portage.tar.xz
Created attachment 878314 [details] qlist-info.txt.xz
Created attachment 878315 [details] sys-apps:heirloom-tools-070715-r6:20231208-132236.log
Created attachment 878316 [details] temp.tar.xz
i'm not at all expert (or even intermediate) in C, but i'm interested to trying to learn how incompatible-pointer-types issues might be resolved for this package. The CVS repo for the Heirloom project doesn't seem to have a Web UI - cf. https://heirloom.cvs.sourceforge.net/heirloom/heirloom/ - so i'll post the relevant code here. In date.c we have: ``` 138 settime(char *op) 139 { 140 struct utmpx before, after; 141 const char wtmpxfile[] = "/var/log/wtmp"; 142 time_t newtime; 143 struct timeval tv; 144 145 memset(&before, 0, sizeof before); 146 memset(&after, 0, sizeof after); 147 before.ut_type = OLD_TIME; 148 after.ut_type = NEW_TIME; 149 strcpy(before.ut_line, "old time"); 150 strcpy(after.ut_line, "new time"); 151 if ((newtime = timeop(op)) == (time_t)-1) 152 badconv(); 153 gettimeofday(&before.ut_tv, NULL); 154 tv.tv_sec = newtime; 155 tv.tv_usec = 0; 156 if (settimeofday(&tv, NULL) < 0) { 157 fprintf(stderr, "%s: no permission\n", progname); 158 exit(1); 159 } 160 gettimeofday(&after.ut_tv, NULL); ... ``` If i change lines 153 and 160 to: ``` gettimeofday((struct timeval *)&before.ut_tv, NULL); ``` and ``` gettimeofday((struct timeval *)&after.ut_tv, NULL); ``` respectively, the specific issue noted in this report is resolved. (Although this then reveals further incompatible-pointer-types issues elsewhere in the code base, e.g. "expected ‘unsigned char **’ but argument is of type ‘char **’". These casts seems reasonable, in that `before` and `after` are local to this function, and i can't see anything being done in the function to make the cast risky. But as i said, i don't claim to be even intermediate in C. If these casts are indeed appropriate, i can move on to examining the other incompatible-pointer-types issues.
