https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: app-i18n/freewnn-1.1.1_alpha23-r1 fails to compile (lto). Discovered on: amd64 (internal ref: lto_tinderbox) NOTE: This machine uses lto with CFLAGS=-flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing
Created attachment 788006 [details] build.log build log and emerge --info
Error(s) that match a know pattern in addition to what has been reported in the summary: /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: <artificial>:(.text+0x1275): undefined reference to `closesocket' <artificial>:(.text+0x120a): undefined reference to `closesocket' <artificial>:(.text+0x39e5): undefined reference to `closesocket' <artificial>:(.text+0x7458): undefined reference to `closesocket' collect2: error: ld returned 1 exit status
I tried to reproduce this but could not get that far, since there were ***too many to count*** instances of -Werror=implicit-function-declaration. As far as I can tell, the source code simply does not believe in the idea of including system headers like, at all? Basically every instance had a note: include ‘<stdlib.h>’ or provide a declaration of XXX note: include ‘<string.h>’ or provide a declaration of XXX There's a small handful of int-conversion issues stemming from the missing function declarations, but it's difficult to tell anything at all from the torrents of noise. The software uses OSDN and is as slow as molasses to load anything, but from what I can make out: - last released in 2015 - they use CVS for development - the one commit since 2015 was a fix for https://reproducible-builds.org """ FreeWnn's dictionary files (*.dic, *.fzk, *.con and *.conR) have the current time, build host name and inode numbers in their headers. So binaries were not "Reproducible Buids"! I changed the atod and atof commands. Now, both commands can ignore the current time, build host name and inode numbers by "-d" option. But FreeWnn identifies files by header information. So "-d" option needs the "dummy device number" option argument. I manage "dummy device number" by "devnum.conf" files. """ Intriguing. Also seems a bit hopeless tbh. The software is too scary to consider where to start fixing it.
hattya, do you have any idea what we can do here? Note the code will horribly miscompile with current compilers and very shortly fail to compile at all with gcc 14, so I think we desperately need someone to check if upstream can be woken up and fix these issues. See https://wiki.gentoo.org/wiki/Modern_C_porting#How_do_I_reproduce_these_bugs.3F for more details.
